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The  Subject  Matter  of  Process  Improvement 


A  Topic  and  Reference  Source  for  Software  Engineering  Educators  and  Trainers 

Abstract:  This  report  provides  a  high-level  topical  overview  of  what  can  be 
taught  or  learned  about  process  improvement.  The  subject  matter  is 
presented  within  a  general  framework  of  six  major  topic  areas,  which  are 
described  and  divided  into  annotated  subtopics.  The  relationships  and 
application  of  the  subject  areas  are  explained  in  the  context  of  process 
improvement  activities.  Topic  areas  range  from  process  and  process 
improvement  concepts  to  tools,  techniques,  teamwork,  and  interpersonal 
skills. 

The  purpose  of  this  report  is  to  assist  software  engineering  educators  and 
trainers  in  selecting  topics  for  curricula  or  training  programs.  It  may  also  be 
used  to  guide  self-study  in  this  area.  Pointers  to  detailed  sources  of 
information  are  given,  but  no  in-depth  information  is  otherwise  provided  for 
the  topic  areas.  Consequently,  this  report  is  not  suitable  for  use  by  itself  as  a 
means  of  learning  the  details  of  how  to  do  process  improvement. 


“Over  the  long  run,  superior  performance  depends  on  superior  learning.” 

— Peter  Senge 

1  Introduction 

Today’s  software  organizations  are  striving  to  remain  competitive  and  healthy.  One  path  to 
providing  a  competitive  edge  lies  in  establishing  an  organizational  culture  driven  by  quality  as¬ 
pirations  and  continuous  improvement.  For  such  organizations  it  is  necessary  that  software 
engineers  and  managers  are  properly  equipped  to  implement  improvements  and  changes. 
The  challenge  for  educators  and  trainers  is  to  ensure  that  adequate  knowledge  and  skills  are 
acquired  so  that  organizations  can  make  rational  decisions  and  carry  them  out  effectively,  i.e., 
to  ensure  that  the  organization  possesses  a  solid  base  of  competency  in  process  improve¬ 
ment. 

Software  engineering  organizations  tell  us  that  they  encounter  obstacles  to  process  improve¬ 
ment  such  as  the  following  [Ibrahim  93a]: 

•  “lack  of  awareness  and  understanding” 

•  “inadequate  training” 

•  “misunderstanding  of  the  importance  of  process  improvement” 

Some  of  the  needs  and  recommendations  we  have  heard  include  the  following: 

•  “We  must  educate  people  on  the  process  so  that  they  understand  why  we’re 
doing  this  as  opposed  to  just  getting  a  ‘good  grade.’” 
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•  “Educate/train  people  from  the  top  down  and  from  the  bottom  up.” 

•  “Get  process  improvement  exposed  more  in  commercial/educational 
organizations.” 

•  “Include  process  improvement  in  formal  software  education  curriculum.” 

We  hope  to  help  overcome  these  obstacles  and  start  meeting  these  needs  by  examining  what 
process  improvement  education  and  training  entails. 

Process  improvement  is  an  emerging  topic  in  software  engineering  education  and  training.  It 
is  so  new  that  the  body  of  knowledge  is  still  evolving,  yet  there  are  considerable  data  available 
regarding  what  one  might  need  to  know.  They  can  be  found  scattered  in  various  courses,  tu¬ 
torials,  workshops,  documents,  articles,  curricula,  standards,  texts,  etc.  They  are  known  by 
those  who  are  working  on  process  improvement  in  the  field,  but  they  have  not  been  compiled 
to  help  software  engineering  educators  and  trainers  offer  the  requisite  knowledge  and  skills 
their  students  need. 

Piecemeal  education  and  training  will  only  offer  piecemeal  solutions  to  the  quality  problems 
we  are  facing  in  the  software  industry.  By  providing  an  overview  of  the  topics  that  make  up 
process  improvement,  we  hope  to  offer  software  engineering  educators  and  trainers  a  broad 
context  from  which  they  can  select  the  most  appropriate  topic  areas  for  their  particular  envi¬ 
ronments. 

This  document  compiles  and  describes  the  subject  matter  of  process  improvement  in  the  hope 
that  it  will  provide  guidance  for  the  design  and  implementation  of  comprehensive  process  im¬ 
provement  education  and  training  for  the  software  engineering  managers  and  practitioners  of 
today  and  tomorrow. 

1.1  Background 

Several  factors  have  motivated  the  preparation  of  this  report.  In  1 992-1 993,  a  survey  was  con¬ 
ducted  by  the  SEI  to  assess  the  needs  of  the  software  community  regarding  Capability  Matu¬ 
rity  Model  for  Software  (CMMSM)*  -based  education  and  training  [Ibrahim  93a].  Survey  results 
indicated  the  need  for  more  focus  and  direction  regarding  process  improvement  education  and 
training,  and  the  need  to  remove  barriers  to  learning. 

At  the  5th  Software  Engineering  Process  Group  National  Meeting  [SEPG  93],  several  papers 
concentrated  on  software  process  improvement  education  and  training  and  a  well-attended 
Birds-of-a-Feather  (BoF)  session  on  Education  and  Training  commenced  with  a  plea  for  “the 
big  picture”  of  what  must  be  taught  [Ibrahim  93b].  Another  BoF  session  was  held  at  the  7th 
Conference  on  Software  Engineering  Education  (CSEE)  [Radice  94]  where  the  exchange  in¬ 
volved  academics  as  well  as  industry  and  government  educators.  That  session  reverberated 
the  need  for  process  education  in  universities. 


*  CMM  is  a  service  mark  of  Carnegie  Mellon  University. 
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The  development  of  this  report  began  in  April  1994.  Shortly  thereafter  more  than  50  people  at 
the  6th  SEPG  Conference  [SEPG  94]  signed  up  expressing  interest  in  this  endeavor.  Inter¬ 
changes  continued  at  the  1994  SEI  Symposium  where  a  focus  group  of  process  improvement 
educators  and  trainers  provided  input  to  this  report  [Focus  94].  The  Pittsburgh  SPIN  (Software 
Process  Improvement  Network)  meeting  in  October  1994  was  a  facilitated  discussion  of  suc¬ 
cesses  and  barriers  to  process  improvement,  and  the  highest  priority  barriers  reported  by  that 
group  were  “Lack  of  understanding  and  knowledge  about  software  process  improvement”  and 
“concepts  aren’t  taught  at  universities”  [Ibrahim  94]. 

This  document  contains  the  beginnings  of  what  the  software  community  has  been  seeking,  in 
the  hope  that  further  work  involving  partners  from  industry,  government,  and  academia  can 
complete  the  picture  and  build  an  infrastructure  equipped  to  provide  education  and  training  in 
process  improvement. 

1 .2  Overview 

This  report  describes  the  subject  matter  of  process  improvement.  It  is  an  initial  compendium 
of  topic  areas  that  make  up  this  aspect  of  software  engineering  endeavor. 

The  report  is  organized  as  follows: 

This  section  presents  audience,  usage,  expectations,  and  scope.  Section  2  describes  the 
method  used  in  preparing  this  report.  An  overview  of  the  subject  matter  framework  and  topic 
breakdown  is  provided  in  Section  3.  Sections  4-9  describe  the  topic  areas:  Process  Funda¬ 
mentals,  Process  Improvement  Fundamentals,  Process  and  Process  Improvement  Manage¬ 
ment,  Culture  Change,  Tools  and  Techniques,  and  Pervasive  Supporting  Skills.  Conclusions, 
including  tailoring  and  delivery  considerations,  are  provided  in  Section  10. 

Process  improvement  includes  improvement  of  the  educational  process  itself,  and  a  separate 
appendix  presents  best  practice  recommendations  from  selected  models  and  standards. 

1.3  Audience  and  Usage 

This  report  is  primarily  intended  for  use  by  educators  and  trainers  in  academic  and  industrial 
settings.  Other  possible  audiences  include  managers,  members  of  software  engineering  pro¬ 
cess  groups  (SEPGs),  change  agents,  and  practitioners  concerned  with  software  process  im¬ 
provement.  We  hope  that  any  members  of  the  software  community  motivated  to  learn  about 
and  carry  out  process  improvement  can  find  information  that  will  help  them  instill  an  improve¬ 
ment  philosophy  in  their  own  work  and  in  their  organizations. 

1.3.1  Academic  Usage 

In  an  academic  setting,  this  work  offers  guidance  in  meeting  the  following  educational  goals: 

•  to  provide  a  specialty  concentration  of  knowledge  and  skills  in  software 
process  improvement 
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•  to  produce  engineering  managers  and  software  engineers  who  are 
equipped  to  contribute  to  process  improvement 

The  following  steps  are  typically  carried  out  to  meet  these  goals: 

•  Decide  the  content  of  the  subject  matter  area  and  describe  it. 

•  Design  a  curriculum  (consider  subsets  of  the  content  appropriate  for  a 
particular  program,  organization,  target  population;  ordering, 
relationships  among  topics  and  subtopics;  packaging,  etc.). 

•  Develop/acquire  courses. 

•  Deliver. 

•  Evaluate  and  revisit  the  above  steps. 

This  document  concentrates  on  the  first  step — deciding  and  describing  the  content  of  the  pro¬ 
cess  improvement  subject  matter  area.  The  academic  audience  will  use  this  subject  matter  de¬ 
scription  to  design  curricula  or  to  develop  courses. 

1.3.2  Industry  Usage 

In  an  industrial  setting,  this  work  offers  guidance  in  meeting  the  following  goal: 

•  to  provide  knowledge  and  skills  to  enable  an  organization  to  improve  its 
process  capability 

Typically  an  organization  might  carry  out  a  knowledge  and  skills  analysis  in  order  to  derive 
data  about  the  knowledge  and  skills  required  for  tasks  performed  by  the  organization’s  busi¬ 
ness  functions  [Curtis  94], 

This  report  may  be  used  as  a  high  level  guidance  profile  of  knowledge  and  skills  pertaining  to 
the  specific  business  function  of  process  improvement.  The  subject  matter  description  is 
based  on  typical  tasks  that  might  be  carried  out  in  any  organization,  and  it  is  intended  to  be 
tailored  by  the  industrial  audience  for  different  needs  and  contexts.  The  report  suggests  topic 
areas  that  might  be  candidates  for  process  improvement  education  and  training  or  for  training 
in  primary  competencies  as  defined  in  Curtis  [Curtis  94]. 

1.3.3  Self-Study  Usage 

For  a  self-study  user  of  this  report,  the  reader  will  be  introduced  to  the  breadth  of  topics  and 
subtopics  of  process  improvement.  No  topic  is  dealt  with  in  sufficient  depth  to  enable  mastery 
because  that  is  not  the  intent  of  this  report.  The  reader  will  get  an  overall  view  of  the  material 
and  will  be  given  extensive  references  for  the  pursuit  of  particular  topics  of  interest. 

1.3.4  Sample  Usage 

Draft  versions  of  this  report  have  been  used  in  the  following  ways: 

•  to  prepare  course  outlines 

•  to  derive  course  bibliographies 
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•  to  design  a  set  of  three  university  courses 

•  to  prepare  lectures  on  selected  topic  areas 

•  to  help  identify  specific  training  needs 

•  to  profile  potential  training  areas 

•  to  prepare  an  executive  briefing 

1 .4  Expectations 

1 .4.1  What  the  Report  Contains 

A  reader  of  this  report  can  expect  to  embark  on  a  tour  through  the  topic  areas  that  make  up 
process  improvement.  This  tour  is  annotated  at  the  major  topic  area  level  and  for  major  sub- 
topics.  Relationships  between  the  topic  areas  are  explained.  Beyond  that,  key  areas  within 
subtopics  are  either  listed,  very  briefly  annotated,  or  noted  by  way  of  examples.  The  bibliog¬ 
raphy  provides  references  for  further  information. 

Thus  the  reader  will  acquire  a  general  knowledge  of  the  subject  matter  of  process  improve¬ 
ment  and  an  awareness  of  the  broad  range  of  topics  in  the  field.The  report  presents  the  topics 
and  shows:  how  they  are  related,  when  they  are  used,  why  they  are  important,  and  where  to 
find  more  information. 

1 .4.2  What  the  Report  Does  Not  Contain 

This  report  does  not  offer  a  simple  solution  to  an  immediate  problem.  It  does  not  dictate  what 
topics  must  be  taught  or  learned  in  any  particular  context,  although  some  tailoring  consider¬ 
ations  are  provided.  It  is  not  possible  to  derive  an  in-depth  knowledge  about  any  of  the  subject 
matter  from  reading  this  document. 

It  is  left  to  the  reader  to  make  judgements,  to  extract  and  package  topic  areas  in  specific  do¬ 
mains,  and/or  to  pursue  learning  goals  by  means  of  further  study. 

1.5  Scope  of  Process  Improvement 

The  scope  of  process  improvement  for  this  report  includes 

•  process  improvement  at  organizational,  process,  and  individual  levels 

•  concepts  and  theory  about  process  improvement  technology  (education) 
as  well  as  skills  in  applying  this  technology  (training) 

•  people  and  cultural  aspects  of  the  process  improvement  environment 

Please  note  that  much  of  the  information  included  pertains  to  “general”  process  improvement 
concepts  and  skills  that  could  be  applied  to  improve  any  process,  but  the  focus  is  on  their  ap¬ 
plication  in  software  engineering  process  improvement. 
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The  scope  excludes 

•  elaboration  of  subject  matter  regarding  process  areas  that  are  already 
well  described,  [such  as  product  engineering  (requirements  analysis, 
design,  coding,  testing,  and  maintenance),  software  configuration 
management,  software  quality  assurance,  software  project  management] 
except  in  the  context  of  more  generic  process  improvement 

•  elaboration  of  subject  matter  in  areas  that  are  judged  to  be  more  product 
oriented  than  process  oriented 

We  recognize  that  competency  in  these  software  engineering  areas  is  essential  and  we  refer 
the  reader  to  other  sources  [Ford  91],  [Shaw  89],  [PMBOK  94]  for  descriptions  of  software  en¬ 
gineering  topic  areas,  academic  programs,  textbooks,  journals,  general  software  engineering 
reference  materials,  and  general  project  management  practices. 
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Method  Used 


2.1  Data  Gathering 

The  basic  approach  to  compiling  this  work  involved  collecting  data  from  the  following  catego¬ 
ries  of  sources: 

•  SEI  courses,  workshops,  tutorials,  services,  and  documents  relating  to 
various  aspects  of  process  improvement 

•  selected  literature,  including  published  standards,  certification,  and 
professional  society  publications 

•  customer  views,  including  experiences,  viewpoints,  and  documents 
provided  by  change  agents,  educators,  and  trainers  in  industry, 
government,  and  academia 

The  strategy  regarding  selection  of  these  sources  was  motivated  by  the  following: 

•  to  abstract  and  coalesce  SEI  process  improvement  guidelines  and 
materials  into  one  general  subject  matter  framework 

•  to  augment  that  basis  with  selected  widely  adopted  standards  and 
approaches  to  process  improvement 

•  to  include  a  full  range  of  topic  areas  covering  the  breadth  of  the  area 

•  to  provide  selected  (but  not  exhaustive)  examples  of  process 
improvement  strategies  being  used  in  the  field 

•  to  validate  and  augment  the  subject  matter  coverage  with  viewpoints  and 
insights  of  practitioners 

•  to  include  extensive  references  to  provide  more  examples  and  details  of 
the  subject  matter 

Accordingly,  the  data  were  collected  through  a  variety  of  approaches  including  informal  ques¬ 
tionnaires,  focus  groups,  and  course  material/document  review.  (See  Appendix  B  for  a  de¬ 
scription  of  customer  data  sources.) 

Whereas  data  reported  from  the  field  contributed  to  this  document,  no  formal  industry-wide  job 
analysis  was  performed  in  compiling  this  information  (e.g.,  [IEEE-CS/ACM  94],  [Westfall  93], 
[ETS  94]).  Nor  was  a  detailed  knowledge  and  skills  analysis  carried  out  involving  first  hand 
study  of  the  roles,  tasks,  and  capabilities  required  for  different  process  improvement  jobs  in 
specific  organizational  contexts.  (See  Curtis  [Curtis  94]  for  guidance  on  how  this  might  be  ac¬ 
complished.) 

For  this  compilation,  we  extracted  the  knowledge  and  skills  already  embedded  in  several  wide¬ 
ly  acknowledged  software  process  improvement  models,  standards,  practices,  and  approach¬ 
es.  The  assumption  is  that  published  approaches  advocated  by  specific  organizations  and 
process  improvement  topics  chosen  by  experts,  educators,  and  trainers  explain  the  knowl¬ 
edge  and  skills  that  are  necessary — or  could  be  useful  generically — to  carry  out  process  im¬ 
provement. 
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2.2  Data  Analysis  and  Structuring 

An  initial  top-down  framework  for  assembling  the  subject  matter  was  established  and  then  re¬ 
vised  as  data  were  gathered  through  a  bottom-up  data  collection  process. 

The  intent  is  to  present  the  topic  areas  so  that  the  information  is  in  a  useful  form  for  educators 
and  trainers  to  extract,  structure,  tailor,  and  evolve  for  their  own  audiences.  Thus  subject  top¬ 
ics  needed  to  be  cohesive  enough  to  comprehend  as  a  unit,  and  modular  enough  to  enable 
combination  with  other  topics  or  inclusion  in  more  traditional  course  offerings. 

Another  analysis  concern  was  the  degree  of  granularity  that  would  be  most  useful  in  a  report 
like  this.  Each  unit  or  topic  area  might  be  expanded  or  contracted  in  different  environments  or 
for  different  needs.  The  intent  is  to  provide  sufficient  content  to  guide  educators  and  trainers 
in  setting  up  programs,  and  give  references  that  offer  additional  detail. 

2.3  The  Review  Process 

This  report  was  reviewed  internally  for  early  drafts,  and  both  internally  and  externally  for  later 
versions.  A  structured  review  session  was  held  on  an  intermediary  draft  and  the  final  draft  un¬ 
derwent  another  internal  review  process.  (See  Appendix  B  for  reviewer  participation.) 
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3  Topic  Areas 

3.1  Describing  Knowledge  and  Skills 

3.1.1  Knowing  and  Doing 

When  describing  knowledge  and  skills,  we  are  describing  what  people  know  and  what  people 
do.  It  is  possible  to  know  something  and  not  do  anything  with  it.  It  is  also  possible  to  do  some¬ 
thing  and  not  know  much  about  it.  What  we  are  trying  to  delineate  here  are  those  essentials 
that  must  be  known  in  order  to  do  process  improvement  in  a  rational  way. 

This  report  offers  essential  knowledge  that  we  hope  will  improve  conventional  thinking,  prac¬ 
tice,  and  organizational  decision  making  about  process  improvement. 

Several  factors  influence  knowledge  use  (technology  transfer)  and  change,  and  several  mod¬ 
els  have  been  proposed  delineating  these  factors.  Some  of  these  approaches  will  be  present¬ 
ed  in  Section  7  (Culture  Change).  One  pervasive  theme  throughout  technology  transfer 
literature  is  that  there  must  be  the  ability  to  carry  out  the  change:  there  must  be  education, 
training,  and  learning.  Thus  the  challenge  to  educators,  trainers,  and  change  agents  is  to 
transfer  this  subject  matter  to  software  engineering  managers  and  practitioners  for  its  effective 
use  in  practice. 

3.1.2  What  is  Knowledge? 

One  definition  of  knowledge  [Glaser  83]  states  that  knowledge  includes 

•  facts,  truths,  and  principles  associated  with  professional  practice 

•  information  or  understanding  based  on  validated,  broad  experience 

•  reliably  identified  exemplary  practice  including  unusual  knowhow 

•  information  certified  as  valid  by  applying  criteria  or  tests 

•  findings  of  validated  research 

One  might  ask,  does  such  a  body  of  knowledge  exist  for  software  process  improvement?  As 
software  evolves  from  a  craft  to  an  engineering  discipline  this  knowledge  is  emerging,  and  as 
process  improvement  gains  more  and  more  momentum  throughout  the  software  community, 
methods  and  experiences  are  becoming  validated  and  documented.  We  are  attempting  to 
identify  that  emerging  body  of  knowledge.  Because  the  field  is  so  new,  we  are  also  including 
selected  software  process  improvement  practices  and  methods  that  are  still  in  the  piloting  or 
developmental  stage. 

Another  view  of  knowledge  and  skills  is  embodied  in  Bloom’s  Taxonomy  of  Educational  Ob¬ 
jectives  [Bloom  56],  This  taxonomy  delineates  a  hierarchy  of  six  increasingly  difficult  levels  of 
achievement: 

•  knowledge:  this  level  is  mainly  concerned  with  terminology  and  facts; 
information  can  be  recalled,  but  there  is  no  deep  understanding. 


CMU/SEI-95-TR-003 


9 


•  comprehension:  materials  can  be  used  in  a  narrow  sense,  can  be 
rephrased,  or  summarized  but  not  extended  or  related  to  other  ideas. 

•  application:  abstractions  can  be  applied  in  particular  situations:  principles, 
techniques,  tools,  and  methods  can  be  remembered  and  applied. 

•  analysis:  the  parts  and  relationships  among  elements  can  be  recognized 
and  identified. 

•  synthesis:  elements  can  be  combined  to  produce  something  new. 

•  evaluation:  value  judgments  can  be  made;  improvements  can  be 
recognized;  suggestions  for  innovation  can  be  made. 

This  taxonomy  puts  “improvement”  at  the  most  complex  achievement  level.  The  hierarchy  also 
implies  that  each  level  builds  on  the  mastery  of  concepts  and  skills  internalized  at  lower  levels 
of  achievement.  The  presentation  that  follows  intends  to  span  Bloom’s  taxonomy.  In  that 
sense  it  describes  the  competency  an  organization  needs  in  order  to  master  process  improve¬ 
ment. 

3.1.3  Competency 

Competency  enables  an  individual  or  an  organization  to  carry  out  activities  that  will  achieve 
desired  outcomes.  It  can  be  considered  a  combination  of  knowledge,  skills,  and  personal  at¬ 
tributes  that  contribute  to  effective  performance.  Knowledge  is  typically  gained  by  education, 
while  skills  are  gained  by  training,  and  attributes  are  gained  by  experience. 

One  approach  we  take  in  the  report  is  to  describe  knowledge,  skills,  and  attributes  in  the  con¬ 
text  of  process  improvement  activities;  activities  are  described,  and  then  examples  of  relevant 
knowledge,  skills,  and  attributes  extracted. 

3.2  The  Framework 

We  evolve  the  subject  matter  by  starting  with  concepts  and  leading  to  their  application  in  pro¬ 
cess  improvement  activities.  Then  we  describe  tools,  techniques,  and  skills  that  can  be  used 
to  help  carry  out  those  activities.  This  know,  do,  use  framework  is  illustrated  in  Table  1 . 


Table  1:  Framework  for  Describing  Process  Improvement  Subject  Matter 


Understand  concepts 

KNOW:  Process  Concepts 

KNOW:  Process  Improvement  Concepts 

Apply  concepts,  make  choices 

DO:  Process  and  Process  Improvement 
Management 

DO:  Culture  Change 

Use  tools,  techniques,  skills 

USE:  Tools  and  Techniques 

USE:  Pervasive  Supporting  Skills 

Although  we  do  not  prescribe  a  specific  ordering  of  topics  and  subtopics  for  delivery  of  this 
material,  we  have  found  this  to  be  a  logical,  rational  approach  to  understanding  the  subject 
matter. 
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We  embellished  this  framework  into  the  topic  and  subtopic  areas  portrayed  in  Table  2. 


Table  2:  Process  Improvement  Topics  and  Subtopics 


Category 

Description 

Topic/Subtopic  References 

KNOW: 

These  are  essential  concepts  that 

Section  4:  Process  Fundamentals 

Process 

must  be  known  or  comprehended 
regarding  the  nature  of  a  process. 

4.1  General  Concepts 

Fundamentals 

They  include  process  maturity,  de¬ 
velopment,  enactment,  modeling, 

4.2  Process  Maturity  Concepts 

definition,  and  measurement  con- 

4.3  Process  Development  and 

cepts.  Software  engineering  pro- 

Enactment  Concepts 

cess  areas  and  processes  are 
included  as  fundamental  knowl¬ 

4.4  Process  Modeling  Concepts 

edge. 

4.5  Process  Definition  Concepts 

4.6  Software  Process 

Measurement 

4.7  Software  Engineering 
Processes 
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Table  2:  Process  Improvement  Topics  and  Subtopics 


Category 

Description 

Topic/Subtopic  References 

KNOW: 

Process 

Improvement 

Fundamentals 

Once  the  nature  of  a  process  is  un¬ 
derstood,  one  can  think  about  pro¬ 
cess  improvement.  Fundamental 
process  and  quality  improvement 
principles  lay  the  foundation,  as 
well  as  familiarity  with  the  teach¬ 
ings  of  the  quality  experts.  Select¬ 
ed  process  improvement 

standards  and  models  are  de¬ 
scribed  as  well  as  improvement 
approaches  that  can  be  applied  at 
an  organizational,  process,  or  indi¬ 
vidual  level. 

Section  5:  Process  Improvement 
Fundamentals 

5.1  Concepts  and  Principles 

5.2  The  Seeds  of  Process 
Improvement 

5.3  Improvement  Models  and 
Standards 

5.4  Process  Appraisal 

5.5  Improvement  Approaches: 
Organizational  Level 

5.6  Improvement  Approaches: 
Process  Level 

5.7  Improvement  Approaches: 
Individual  Level 

DO: 

Process 

and 

Process 

Improvement 

Management 

Now  one  starts  to  apply  the  knowl¬ 
edge  described  in  the  first  two  cat¬ 
egories.  We  describe  what  is  done 
in  carrying  out  process  improve¬ 
ment  at  various  levels  and  extract 
example  knowledge  and  skills 
used  in  carrying  out  those  activi¬ 
ties.  These  include  analysis  and 
synthesis  of  improvement  meth¬ 
ods,  evaluation  and  judgment  in 
making  rational  improvement 
choices,  and  using  selected  tools 
and  techniques. 

Section  6:  Process  and  Process 
Improvement  Management 

6.1  Process  Improvement 
Management 

6.2  Process  Management 

6.3  Organizational  Process 
Management 
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Table  2:  Process  Improvement  Topics  and  Subtopics 


Category 

Description 

Topic/Subtopic  References 

DO: 

Culture  Change 

Does  culture  change  have  any¬ 
thing  to  do  with  software  process 
improvement?  Do  software  engi¬ 
neers  need  to  understand  organi¬ 
zational  culture  and  dynamics?  We 
know  that  culture  or  resistance  to 
change  are  frequently  cited  as  ma¬ 
jor  barriers  to  improvement  efforts. 
This  part  of  the  framework  de¬ 
scribes  the  nature  of  a  quality  cul¬ 
ture,  culture  change  concepts,  and 
approaches  to  changing  culture. 

Section  7:  Culture  Change 

7.1  Directions 

7.2  Change  Concepts 

7.3  Change  Strategies 

USE: 

Tools  and 
Techniques 

This  category  includes  more  de¬ 
tails  about  tools  and  techniques 
used  in  process  improvement  ac¬ 
tivities. 

Section  8:  Process  Improvement 
Tools  and  Techniques 

8.1  Customer  Value 

8.2  Problem  Solving 

8.3  Statistical  Techniques 

8.4  Cost/Benefit  Analysis 

8.5  Risk  Assessment  Techniques 

8.6  Defect  Detection  and 

Prevention 

8.7  Benchmarking 

8.8  Process  Definition 

8.9  Process  Measurement 
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Table  2:  Process  Improvement  Topics  and  Subtopics 


Category 

Description 

Topic/Subtopic  References 

USE: 

Pervasive 

Supporting 

Skills 

This  last  part  of  the  framework  ad¬ 
dresses  “people”  skills  that  per¬ 
vade  most  process  improvement 
activities.  These  include  key  skills 
that  form  the  foundation  of  a  quality 
culture  such  as  teamwork,  commu¬ 
nication,  and  human  interaction. 

Section  9:  Pervasive  Supporting 
Skills 

9.1  Teamwork  Skills 

9.2  Communication  Skills 

9.3  Interaction  Skills 

9.4  Consulting  Skills 

9.5  Behavioral  Change  Skills 
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4  Process  Fundamentals 


“An  important  first  step  in  addressing  the  software  problems  is  to  treat  the  entire 
software  task  as  a  process  that  can  be  controlled,  measured,  and  improved.” 

— Watts  Humphrey 

We  start  off  by  considering  fundamental  process  concepts:  what  is  a  process,  what  can  one 
do  with  a  process,  and  what  are  examples  of  software  engineering  processes.  This  section 
includes:  General  Concepts,  Process  Maturity  Concepts,  Process  Development  and  Enact¬ 
ment  Concepts,  Process  Modeling  Concepts,  Process  Definition  Concepts,  Software  Process 
Measurement,  and  Software  Engineering  Processes. 


4.1  General  Concepts 

Process  is  what  people  do,  using  procedures,  methods,  tools,  and  equipment,  to  transform 
raw  material  (input)  into  a  product  (output)  that  is  of  value  to  customers.  A  software  organiza¬ 
tion,  for  example,  uses  its  resources  (people,  and  material)  to  add  value  to  its  inputs  (customer 
needs)  in  order  to  produce  outputs  (software  products). 

Process.  A  sequence  of  steps  performed  for  a  given  purpose  [IEEE-STD- 
610], 

Software  Process.  A  set  of  activities,  methods,  practices,  and 
transformations  that  people  use  to  develop  and  maintain  software  and  the 
associated  products  [Paulk  93a]. 

Processes  exist  at  various  levels,  and  serve  general  or  specific  goals.  At  the  organization  lev¬ 
el,  processes  interact  broadly  with  the  environment  or  seek  organization-wide  goals;  at  the  tac¬ 
tical  and  operational  levels,  processes  serve  specific  project  or  functional  goals;  at  the 
individual  level,  processes  accomplish  specific  tasks. 

The  process  management  premise  is  that  the  quality  of  the  product  (e.g.  a  software  system) 
is  largely  governed  by  the  quality  of  the  process  used  to  develop  and  maintain  it. 

Process  context.  Organizations  as  systems  with  strategic,  technical, 
structural,  cultural,  and  managerial  components;  relation  of  process  to  other 
components  of  organizational  systems;  people,  process,  and  technology  as 
three  quality  leverage  points;  relating  process  and  product;  relating  to 
external  forces;  process  levels;  formal  and  informal  processes. 


4.2  Process  Maturity  Concepts 

Processes  can  be  characterized  in  terms  of  capability,  performance,  and  maturity. 

Software  process  maturity.  The  extent  to  which  a  specific  process  is 
explicitly  defined,  managed,  measured,  controlled,  and  effective  [Paulk  93a]. 
The  maturity  of  an  organization’s  software  process  helps  to  predict  a  project’s 
ability  to  meet  its  goals. 
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Software  process  capability.  The  range  of  expected  results  that  can  be 
achieved  by  following  a  software  process  [Paulk  93a].  A  more  mature  process 
has  improved  capability  (a  narrower  range  of  expected  results). 

Software  process  performance.  The  actual  results  achieved  by  following  a 
software  process  [Paulk  93a].  A  more  mature  process  has  improved 
performance  (lower  costs,  lower  development  time,  higher  productivity  and 
quality)  and  performance  is  more  likely  to  meet  targeted  goals. 

Maturity  model.  A  representation  of  the  key  attributes  of  selected 
organizational  entities  which  relate  to  the  progress  of  the  entities  towards 
reaching  their  full  growth  or  development  [Garcia  93], 

Institutionalization.  Building  an  infrastructure  and  a  corporate  culture  that 
supports  the  methods,  practices,  and  procedures  of  the  business  so  that  they 
endure  after  those  who  originally  defined  them  have  gone;  an  organization 
institutionalizes  its  software  process  via  policies,  standards,  and 
organizational  structures  [Paulk  93a]. 


4.3  Process  Development  and  Enactment  Concepts 

Core  concepts  are  emerging  about  software  process.  To  meet  the  need  for  a  common  com¬ 
munication  framework  on  software  process,  a  small  group  headed  by  Peter  Feiler  and  Watts 
Humphrey  proposed  a  core  set  of  terms  covering  the  basic  set  of  abstract  process  concepts. 
The  scope  of  the  concepts  was  limited  to  definition,  modeling,  and  enactment  issues.  Feiler 
documents  these  concepts,  which  are  fundamental  knowledge  for  those  working  in  software 
process  [Feiler  92].  They  are  outlined  below: 

Framework  for  Process  Definition.  These  are  the  basic  process  artifacts, 
which  include 

•  process  architecture:  a  conceptual  framework  for  consistently 
incorporating,  relating,  and  tailoring  process  elements  into  enactable 
processes 

•  process  design:  an  embodiment  of  a  process  architecture. 

•  process  definition:  an  enactable  implementation  of  a  process  design  in 
the  form  of  a  partially  ordered  set  of  process  steps. 

•  process  plan:  a  specification  of  the  resources  necessary  for  enactment 
of  a  process  definition 


Engineering  of  Processes.  These  concepts  relate  to  engineering  of 
processes,  itself  a  process  that  can  be  engineered  and  defined: 

•  development:  creating  process  architectures,  process  designs,  or 
process  definitions 

•  tailoring:  adapting  process  designs  and  process  definitions  to  support 
the  enactment  of  a  process  for  a  particular  purpose 

•  planning:  developing  a  process  plan  for  the  enactment  of  a  process 
definition 
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instantiation:  creating  enactable  processes  from  process  definitions 
evolution:  changing  existing  process  definitions 


Enactment  of  processes.  Concepts  are  grouped  into  four  areas. 

•  process  enactment:  the  mechanics  of  enacting  a  process  (agent, 
process  constraint,  enactment  state,  enacting  process,  interaction, 
automation) 

•  process  control:  monitoring,  analysis,  and  adjustment  of  a  process  to 
improve  its  behavior(control  process,  monitoring,  process  trace,  analysis, 
adjustment) 

•  process  authority:  authorization,  appraisal,  delegation,  and  intrusion 

•  process  assurance:  methods  of  adapting  a  process  definition  to  address 
unexpected  situations,  and  means  for  ensuring  proper  enactment  of  the 
established  process  definition  (repair,  recovery,  enforcement,  guidance) 


Process  properties.  These  properties  relate  to  entire  processes  or  elements 
of  processes. 

•  static  properties:  accuracy,  fidelity,  fitness,  precision,  redundancy, 
scalability,  maintainability 

•  dynamic  properties:  lifeness,  robustness,  fault  tolerance,  autonomy, 
responsiveness 

4.4  Process  Modeling  Concepts 

Just  as  a  software  program  defines  a  process  that  a  computer  must  follow  to  achieve  a  result, 
software  process  models  define  the  process  a  software  engineer  follows.  A  software  process 
model  can  be  a  descriptive  representation  of  the  structure  of  a  software  process  or  a  prescrip¬ 
tive  representation  that  defines  how  a  process  carries  out  its  activities.  Because  of  fundamen¬ 
tal  parallels  between  defining  and  modeling  organizational  processes  and  computer 
processes,  many  techniques  from  computer  process  representation  can  be  applied  to  organi¬ 
zational  process  representation. 

Software  process  modeling  objectives,  facilitate  human  understanding 
and  communication,  support  process  improvement,  support  process 
management,  automate  guidance  in  performing  process,  automate  execution 
support. 

Representation  techniques.  IDEFO,  SADT,  activity  charts,  module  charts, 
state  charts,  Entry-Task-Validation-Exit  (ETVX),  flowcharts,  data  flow 
diagrams,  languages,  etc. 

Process  modeling  paradigms.  Programming  models  (process 
programming),  functional  models  (HFSP),  plan-based  models  (GRAPPLE), 
petri-net  models  (role  interaction  net),  quantitative  models. 
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4.5  Process  Definition  Concepts 

Process  definition  consists  of  adding  and  organizing  information  to  a  process  model  to  ensure 
it  can  be  enacted.  A  process  is  defined  when  it  has  documentation  detailing  what  is  done,  who 
does  it,  the  materials  needed  to  do  it,  and  what  is  produced.  A  software  process  definition  es¬ 
tablishes  a  plan  for  applying  tools,  methods,  and  people  to  the  task  of  software  development. 
(See  also  8.8) 

Process  definition  activities.  Product  planning,  process  familiarization, 
customer  identification,  interviewing,  analysis,  model  construction, 
verification  and  validation. 

Components  of  software  definition.  A  software  definition  document  will 
consist  of  information  about  work  product,  activity,  and  agent  viewpoints.  That 
is,  the  document  identifies  work  products  to  be  produced,  activities,  and  the 
agents  involved  in  producing  the  work  products. 

Related  terms  and  concepts.  Process  design,  process  management 
principles,  life-cycle-models,  descriptive  modeling,  prescriptive  modeling, 
organizational  process  asset,  perspective  viewpoint,  process  asset,  process 
model,  process  guide. 


4.6  Software  Process  Measurement 

The  primary  purpose  of  measurement  is  to  provide  insight  into  software  processes  and  the 
products  that  such  processes  produce.  (See  also  Section  8.9)  Type  and  level  of  granularity  of 
a  measurement  depend  on  the  goals  of  the  measurement  program.  The  Goal-Question-Metric 
(G-Q-M)  paradigm  [Basili  84]  is  one  framework  for  establishing  a  measurement  program. 

Goal.  Define  goals  for  the  measurement  program. 

Question.  Develop  questions  that  help  determine  whether  or  not  goals  are 
being  met. 

Measure.  Identify  quantifiable  answers  to  the  questions. 

Here  are  some  examples  of  software-related  measures. 

Product  measures.  The  SEI  has  proposed  four  core  product  measures 
[Carleton  92]  upon  which  other  metrics  are  built:  Size — source  statements, 
function  points;  Effort—  person-hours  (dollars);  Schedule — elapsed  time; 
Quality— problems  and  defects. 

Process  measures.  Number  of  defects  per  KLOC  (thousands  of  lines  of 
code),  function  points  per  staff  months,  defects  found  each  phase  of 
development,  percentage  of  defects  found  before  functional  verification  test. 

Quality/reliability  measures.  Defect  quantities,  defect  severities,  defect 
reports  for  same  defect,  efficiency  of  testing  in  defect  removal,  mean  time  to 
failure. 

User  satisfaction  measures.  User  defect  report,  customer  satisfaction 
indices,  user  requests  for  enhancement. 
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4.7  Software  Engineering  Processes 

Software  processes  have  been  categorized  and  structured  in  different  ways.  Two  major  pro¬ 
cess  breakdowns  are  described  below. 

4.7.1  Processes  and  Process  Categories  in  the  SPICE*  Baseline 
Practices  Guide 

The  SPICE  Baseline  Practices  Guide  [SPICE-BPG  94]  documents  the  set  of  practices  consid¬ 
ered  essential  to  good  software  engineering.  The  base  practices  are  grouped  into  processes. 
Sets  of  processes  that  should  be  implemented  to  establish  and  improve  an  organization’s  soft¬ 
ware  development,  maintenance,  operation,  and  support  capabilities  are  organized  into  pro¬ 
cess  categories  that  address  the  same  general  area  of  activity.  Table  3  shows  the  five  process 
categories  and  their  member  processes.  (Section  5.3.4  describes  the  basic  structure  of  the 
SPICE  standard  and  its  BPG.) 


Table  3:  Processes  and  Process  Categories  in  SPICE  BPG 


Process  Categories 

Processes 

Customer-Supplier  Process  Category: 

processes  that  directly  affect  the  customer, 
support  development  and  transition  of  the 
software  to  the  customer,  and  provide  for  its 
correct  operation  and  use 

Acquire  software  product  and/or  service;  es¬ 
tablish  contract;  identify  customer  needs; 
perform  joint  audits  and  reviews;  package, 
deliver,  and  install  the  software;  support  op¬ 
eration  of  software;  provide  customer  ser¬ 
vice;  assess  customer  satisfaction. 

Engineering  Process  Category:  process¬ 
es  that  directly  specify,  implement,  or  main¬ 
tain  a  system  and  software  product  and  its 
user  documentation 

Develop  system  requirements  and  design; 
develop  software  requirements;  develop 
software  design;  implement  software  de¬ 
sign;  integrate  and  test  software;  integrate 
and  test  system;  maintain  system  and  soft¬ 
ware. 

Project  Process  Category:  processes  that 
establish  the  project,  and  coordinate  and 
manage  its  resources  to  produce  a  product 
or  provide  services  which  satisfy  the  cus¬ 
tomer 

Plan  project  life  cycle;  establish  project  plan; 
build  project  teams;  manage  requirements; 
manage  quality;  manage  risks;  manage  re¬ 
sources  and  schedule;  manage  subcontrac¬ 
tors. 

•  In  January  1993  an  international  working  group  (WG10)  was  formed  as  part  of  the  international  standards  body 
ISO  (the  International  Organization  for  Standardization)  and  IEC  (*the  International  Electrotechnical  Commission) 
JTC1  (Joint  Technical  Committee  1)  SC7  (Sub  Committee  7)  (ISO/IEC  JTC1/SC7).  The  purpose  of  Working 
Group  10  is  to  create  a  standard  for  Software  Process  Assessment,  and  the  mechanism  used  to  accomplish  this 
was  to  form  a  separate  project  called  SPICE  (Software  Process  Improvement  and  Capability  Determination). 
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Table  3:  Processes  and  Process  Categories  in  SPICE  BPG 


Process  Categories 

Processes 

Support  Process  Category:  processes 
that  enable  and  support  the  performance  of 
the  other  processes  on  a  project 

Develop  documentation;  perform  configura¬ 
tion  management;  perform  quality  assur¬ 
ance;  perform  problem  resolution;  perform 
peer  reviews 

Organization  Process  Category:  process¬ 
es  that  establish  the  business  goals  of  the 
organization  and  develop  process,  product, 
and  resource  assets  which  will  help  the  or¬ 
ganization  achieve  its  business  goals 

Engineer  the  business;  define  the  process; 
improve  the  process;  perform  training;  en¬ 
able  reuse;  provide  software  engineering 
environment;  provide  work  facilities. 

4.7.2  Key  Process  Areas  in  the  Capability  Maturity  Model  for  Software 
(CMM)  * 

“Each  key  process  area  identifies  a  cluster  of  related  activities  that,  when 
performed  collectively,  achieve  a  set  of  goals  considered  important  for 
enhancing  process  capability.”  — CMM  for  Software 

The  CMM  [Paulk  93a]  presents  a  set  of  recommended  practices  in  eighteen  key  process  areas 
(KPAs)  that  have  been  shown  to  enhance  software  development  capability  [Herbsleb  94]. 
Each  KPA  resides  at  a  single  maturity  level.  The  1 8  Key  Process  Areas  have  been  categorized 
into  three  broad  categories:  management,  organizational,  and  engineering  processes  [Paulk 
93b].  The  maturity  levels,  KPAs,  and  categorizations  are  shown  in  Table  4.  Note  that  at  Levels 
4  and  5  there  are  KPAs  that  span  process  categories,  and  that  no  KPAs  are  associated  with 
the  Initial  Level.  (Section  5.3.1  describes  the  basic  structure  of  the  CMM.) 


■  In  1986,  the  Software  Engineering  Institute  (SEI),  with  assistance  from  Mitre  Corporation,  began  developing  a 
process  maturity  framework  that  would  help  organizations  improve  their  software  process.  After  four  years  of  ex¬ 
perience  with  this  framework,  the  SEI  evolved  the  software  process  maturity  framework  into  the  Capability  Matu¬ 
rity  Model  for  Software  (CMM).  The  initial  release  of  the  CMM  was  reviewed  and  used  by  the  software  community 
during  1991  and  1 992  and  revised  based  on  ongoing  feedback  from  the  software  community. 
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Table  4:  The  Key  Process  Areas  by  Maturity  Level  and  Process  Category 


Management 

Organizational 

Engineering 

Levels 

5  Optimizing.  At  the  Opti¬ 
mizing  level,  continuous 
process  improvement  is 
enabled  by  quantitative 
feedback  from  the  process 
and  from  testing  innovative 
ideas  and  technologies. 

Process  Change 
Management 

Technology 

Change 

Management 

Process  Change 
Management 

Technology 

Change 

Management 

Defect  Prevention 

4  Managed.  At  the  Man¬ 
aged  level,  detailed  mea¬ 
sures  of  the  software 
process  and  product  quali¬ 
ty  are  collected.  Both  the 
software  process  and  prod¬ 
ucts  are  quantitatively  un¬ 
derstood  and  controlled 
using  detailed  measures. 

Quantitative 

Process 

Management 

Quantitative 

Process 

Management 

Software  Quality 
Management 

3  Defined.  At  the  Defined 
level,  the  software  process 
for  both  management  and 
engineering  activities  is 
documented,  standardized, 
and  integrated  into  an  orga¬ 
nization-wide  software  pro¬ 
cess.  All  projects  use  a 
documented  and  approved 
version  of  the  organiza¬ 
tion’s  process  for  develop¬ 
ing  and  maintaining 

software. 

Integrated 

Software 

Management 

Intergroup 

Coordination 

Organization 
Process  Focus 

Organization 
Process  Definition 

Training  Program 

Software  Product 
Engineering 

Peer  Reviews 
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Table  4:  The  Key  Process  Areas  by  Maturity  Level  and  Process  Category 


Levels 

Management 

Organizational 

Engineering 

2  Repeatable.  At  the  re¬ 
peatable  level,  basic 
project  management  pro¬ 
cesses  are  established  to 
track  cost,  schedule,  and 
functionality.  The  neces¬ 
sary  process  discipline  is  in 
place  to  repeat  earlier  suc¬ 
cesses  on  projects  with 
similar  applications. 

Requirements 

Management 

Software  Project 
Planning 

Software  Project 
Tracking  & 
Oversight 

Software 

Subcontract 

Management 

Software  Quality 
Assurance 

Software 

Configuration 

Management 

1  Initial 

Ad  Hoc  Processes 

Ad  Hoc  Processes 

Ad  Hoc  Processes 
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5  Process  Improvement  Fundamentals 


“Improve  constantly  and  forever  the  system  of  production  and  service,  to 
improve  quality  and  productivity,  and  thus  constantly  decrease  costs.” — W. 

Edwards  Deming 

Quality  has  been  a  business  concern  for  several  decades,  but  a  major  innovation  in  software 
organizations  has  been  the  shift  from  the  product  to  the  process  as  the  focus  for  quality  control 
and  improvement. 

This  section  describes  fundamentals  that  provide  essential  knowledge  for  pursuing  process 
improvement.  Our  premise  is  that  process  improvement  can  only  become  internalized  and 
continuous  when  it  is  based  on  knowledge  and  understanding  of  the  principles  that  have 
caused  major  quality  changes  in  other  business  domains.  But  do  these  principles  apply  to  soft¬ 
ware?  Yes.  They  have  been  captured  in  widely  adopted  standards  and  models  that  apply  them 
to  the  software  process.  These  standards  continue  to  evolve  as  software  process  improve¬ 
ment  becomes  a  more  mature  discipline  and  practice.  Many  approaches  to  software  process 
improvement  exist  and  are  emerging.  We  include  these  essentials  in  this  section. 

First,  major  process  improvement  concepts  and  principles  are  presented  in  order  to  depict  cur¬ 
rent  thinking  on  the  underpinnings  of  process  and  quality  improvement.  Then,  brief  introduc¬ 
tions  are  made  to  the  philosophies  of  the  major  quality  leaders. 

The  next  two  sections  present  selected  improvement  models  and  standards,  which  provide 
guidance  on  improvement  aspirations;  and  process  appraisal  fundamentals,  which  underlie 
methods  used  to  characterize  current  practice  in  relation  to  goals. 

Improvement  can  be  carried  out  at  several  process  levels  and  through  various  approaches  at 
these  levels.  The  last  three  sections  describe  a  variety  of  improvement  approaches  at  organi¬ 
zational,  process,  and  individual  levels. 

5.1  Concepts  and  Principles 

This  section  captures  major  concepts  and  principles  that  underlie  process  and  quality  improve¬ 
ment.  These  principles  provide  the  foundation  for  carrying  out  process  improvement  activities. 

5.1.1  Some  Definitions 

Process  improvement  and  quality  improvement  are  deeply  entwined. 

Process  and  quality  improvement.  The  operation  of  putting  in  place 
measures  to  strengthen  weaknesses  in  processes  which  have  been  identified 
as  sources  of  defects  and  risks  to  quality.  Process  and  quality  improvement 
is  based  on  the  premise  that  product  quality  is  highly  dependent  on  the 
processes  used  in  its  development  [ImprovelT  91]. 
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Quality  improvement.  Actions  taken  throughout  the  organization  to  increase 
the  effectiveness  and  efficiency  of  activities  and  processes,  and  to  provide 
added  benefits  to  both  the  organization  and  its  customers  [ISO  9004-4  93]. 

Quality  losses.  Losses  caused  by  not  realizing  the  potential  of  resources  in 
processes  and  activities  [ISO  9004-4  93]. 

5.1.2  General  Principles  of  Process  Improvement 

Several  general  principles  of  process  improvement  emerge  repeatedly  from  the  process  im¬ 
provement  literature.  Pervasive  themes  include: 

Management.  Major  changes  must  start  at  the  top;  enabling  quality 
improvement  is  a  management  responsibility;  management  must  visibly 
endorse  and  support  process  improvement. 

Involvement.  Everyone  must  be  involved;  successful  change  requires  a 
team  effort. 

Assessment/measurement.  Effective  change  requires  a  goal  and 
knowledge  of  the  current  process;  understand  the  current  process  first;  to  use 
a  map  you  must  know  where  you  are;  quality  improvement  must  be 
measured. 

The  nature  of  change.  Change  is  continuous;  change  is  normal;  every 
defect  is  an  improvement  opportunity. 

Investment.  Improvement  requires  investment;  improvement  requires  time, 
skill,  and  money. 

Reinforcement.  Sustaining  change  requires  periodic  reinforcement;  rewards 
and  incentives  are  necessary  to  establish  and  maintain  an  improvement 
effort. 

Prevention.  Crisis  prevention  is  more  important  than  crisis  recovery. 

Process.  Quality  improvement  focuses  on  fixing  the  process,  not  the  people; 
quality  improvement  is  a  continuous  process. 

5.1.3  Quality  Concepts  and  Principles 

The  following  are  some  examples  of  concepts  and  principles  that  underly  specific  quality  stan¬ 
dards  and  practices. 

5. 1.3.1  ISO  9000  Concepts  and  Principles 

The  ISO  9000  series  of  standards  were  developed  by  the  International  Organization  for  Stan¬ 
dardization.  These  standards  deal  with  quality  management  systems  and  they  have  been 
adopted  as  national  quality  standards  by  over  50  countries. 
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Principles  of  quality  improvement  [ISO  9004-4  93] 

Quality  of  an  organization’s  products,  services  and  other  outputs  is  deter¬ 
mined  by  the  satisfaction  of  the  customers  who  use  them  and  results  from 
the  effectiveness  and  efficiency  of  the  processes  that  create  and  support 
them. 

Quality  improvement  is  achieved  by  improving  processes;  quality  im¬ 
provement  is  a  continuous  activity. 

Seek  opportunities  for  improvement,  rather  than  waiting  for  a  problem  to 
reveal  opportunities;  opportunities  to  reduce  quality  losses  guide  quality 
improvement. 

Preventive  and  corrective  actions  improve  the  processes  of  an  organiza¬ 
tion. 

Quality  concepts  for  quality  management  systems  [ISO  9004  87] 

An  organization  should  achieve  and  sustain  the  quality  of  the  product  or 
service  produced  to  meet  continually  the  purchaser’s  stated  or  implied 
needs. 

An  organization  should  provide  confidence  to  its  own  management  that 
the  intended  quality  is  being  achieved  or  sustained. 

An  organization  should  provide  confidence  to  the  purchaser  that  the  in¬ 
tended  quality  is  being,  or  will  be,  achieved  in  the  delivered  product  or  ser¬ 
vice  provided. 

5.1 .3.2  Total  Quality  Management  Principles 

Total  Quality  Management  (TQM)  is  the  application  of  quantitative  methods  and  human  re¬ 
sources  to  improve:  the  material  and  services  supplied  to  an  organization,  all  the  processes 
within  an  organization,  and  the  degree  to  which  the  needs  of  the  customer  are  met  both  now 
and  in  the  future  [DOD-TQM  91],  [DOD-TQM  89b]. 

Basic  TQM  principles.  Continuous  process  improvement,  process 
knowledge,  user  focus,  commitment,  top-down  implementation,  constancy  of 
purpose,  total  involvement,  teamwork,  and  investment  in  people. 

TQM  focus.  Emphasize  continuous  improvement  of  processes,  not 
compliance  to  standards;  motivate  to  improve  from  within,  rather  than  wait  for 
complaints/demands  from  users;  involve  all  functions,  not  just  the  quality 
organization;  motivate  and  involve  employees  to  become  the  driving  force  for 
improvement;  satisfy  the  customer,  not  merely  conform  to  requirements;  use 
guides  and  target  values  as  goals  for  improvement,  not  standards  to  which  to 
conform;  use  modern  process  control  techniques;  and  understand  the  effects 
of  variation  on  processes  and  their  implications  for  process  improvement. 
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5.1 .3.3  Quality  Leadership  Principles 

Quality  Leadership  is  a  management  style  or  practice  that  shifts  emphasis  from  profits  to  qual¬ 
ity  [Scholtes  88]. 

Quality  Leadership  principles.  Customer  focus,  obsession  with  quality, 
recognizing  the  structure  in  work,  freedom  through  control,  unity  of  purpose, 
looking  for  faults  in  systems,  teamwork,  and  continuous  education  and 
training. 

5.1. 3.4  Leadership  Through  Quality  Principles 

Leadership  Through  Quality  (LTQ)  is  a  process  used  by  Xerox  Corporation  that  is  aimed  at 
fundamentally  changing  the  way  people  work  and  manage  so  that  they  can  continuously  im¬ 
prove  the  way  they  meet  the  requirements  of  their  customers  [XEROX  86]. 

Quality  principles.  Quality  is  the  basic  business  principle  for  Xerox  to 
continue  to  be  a  leadership  company;  we  will  understand  our  customer’s 
existing  and  latent  requirements;  we  will  provide  all  our  external  and  internal 
customers  products  and  services  which  meet  their  requirements;  employee 
involvement,  through  participative  problem  solving,  is  essential  to  improve 
quality;  and  error-free  work  is  the  most  cost  effective  way  to  improve  quality. 

5.2  The  Seeds  of  Process  Improvement 

This  section  overviews  major  philosophies  and  principles  offered  by  experts  who  brought  the 
world’s  attention  to  quality,  including  W.  Edwards  Deming,  Joseph  M.  Juran,  Philip  B.  Crosby, 
and  Masaaki  Imai. 

5.2.1  Management  Philosophy  of  Deming 

W.  Edwards  Deming  is  a  renowned  leader  in  the  quality  movement.  His  work  [Deming  86]  is 
seminal  in  this  area  and  his  ideas  pervade  improvement  philosophy  and  efforts. 

“ Everyone  in  this  field  should  be  familiar  with  Deming’s  work.’’  — Watts 
Humphrey 

Quality.  Quality  is  defined  by  the  customer. 

The  Deming  Chain  Reaction.  Improve  quality,  decrease  costs,  improve 
productivity,  decrease  prices,  increase  market,  stay  in  business,  provide  jobs 
and  more  jobs,  return  on  investment. 

Transformation.  The  Fourteen  Points;  the  Seven  Deadly  Diseases; 
Obstacles;  and  the  Deming  Prize. 

Statistics.  Basing  decisions  on  accurate,  timely  data;  role  of  statistics  to  help 
understand,  control,  and  improve  processes;  special  causes  of  variability  and 
eliminating  them;  common  causes  of  variability  and  of  poor  quality;  and 
quality  diagnosis. 
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A  company’s  extended  process.  Manpower,  methods,  materials,  machines 
PLUS  suppliers,  customers,  investors,  and  the  community;  the  idea  of  a 
system  with  supportive  components  working  together  (everyone  wins). 

Responsibility.  Management’s  responsibility  for  the  process;  worker’s 
responsibilities  to  communicate  to  management;  interdisciplinary  teams;  and 
the  need  for  cooperation. 

5.2.2  Management  Philosophy  of  Juran 
Quality.  Quality  is  fitness  for  use. 

The  Juran  trilogy  of  quality  management.  Quality  planning  (providing 
resources),  quality  control  (preventing  quality  deficiencies  from  getting 
worse),  and  quality  improvement  (seizing  opportunities  to  reduce  chronic 
waste). 

The  costs  of  poor  quality.  Cost  of  inappropriate  product  design,  cost  of 
ineffective  development/manufacturing  processes,  and  cost  of  rework. 

Structured  annual  improvements  in  quality.  Study  the  symptoms  of 
defects  and  failures;  develop  a  theory  on  the  causes  of  these  symptoms;  test 
the  theory  until  the  cause(s)  is  known;  and  stimulate  remedial  action  by  the 
appropriate  departments. 

A  massive  quality-oriented  training  program. 

Upper  management  leadership.  Leadership  of  each  company’s  approach 
to  product  quality. 

Pareto  principle.  Concentrate  on  the  vital  few,  not  the  trivial  many. 

5.2.3  Management  Philosophy  of  Crosby 

“Quality  is  an  achievable,  measurable,  profitable  entity  that  can  be  installed 
once  you  have  commitment  and  understanding,  and  are  prepared  for  hard 
work.” — Philip  Crosby 

Quality.  Quality  is  conformance  to  requirements. 

Cost  of  quality.  Measured  by  the  expense  of  nonconformance;  the  cost  of 
doing  things  wrong. 

Quality  management.  Systematic  way  of  guaranteeing  that  organized 
activities  happen  the  way  they  are  planned. 

The  Quality  Management  Maturity  Grid.  Stages:  Uncertainty,  Awakening, 
Enlightenment,  Wisdom,  Certainty;  Measurement  categories:  management 
understanding  and  attitude,  quality  organization  status,  problem  handling, 
cost  of  quality  as  a  percent  of  sales,  quality  improvement  actions,  and 
summation  of  company  quality  posture. 
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5.2.4  Quality  Work  in  Japan 

It  is  called  Kaizen. 

“Kaizen  means  ongoing  improvement  involving  everyone.” — Masaaki  Imai 

In  Kaizen,  the  key  to  Japan’s  competitive  success,  Masaaki  Imai  brings  together  the  manage¬ 
ment  philosophies,  theories,  and  tools  that  have  been  developed  and  used  over  the  years  in 
Japan  [Imai  86], 

Concepts.  Belief  in  unending  improvement,  responsibility  for  maintenance 
and  improvement,  process  orientation  and  people  orientation  (not  result 
orientation);  The  P  criteria:  discipline,  time  management,  skill  development, 
participation  and  involvement,  morale,  and  communication. 

Kaizen  by  Total  Quality  Control  (TQC).  Company-wide  quality  control; 
quality  culture:  building  quality  into  people  through  training  and  leadership; 
training  and  education  for  everyone]  speak  with  data;  quality  first  (not  profit 
first);  the  five  “whys”;  customer  orientation;  cross-functional  management; 
and  Plan-Do-Check-Act.  (See  also  Section  5.4.7) 

Kaizen  in  practice.  Management-oriented  kaizen,  group-oriented  kaizen, 
individual-oriented  kaizen. 

Management  concepts.  Cross-functional  management;  policy  deployment; 
quality,  cost,  and  scheduling  goals;  rewarding  effort,  not  just  results;  and 
customer  orientation. 

Problem  solving.  Problems  as  potential  for  improvement;  identifying  and 
reporting  problems;  top-down  (design)  approach;  bottom-up  (analytical) 
approach;  The  Seven  Statistical  Tools  for  analytical  problem  solving;  The 
New  Seven  tools  for  design.  (See  Section  8.) 

5.3  Improvement  Models  and  Standards 

Knowledge  of  improvement  models  and  standards  guides  improvement  efforts  and  ensures 
rational  choice  regarding  the  model  to  be  followed  or  tailored  for  the  organization.  These  mod¬ 
els  and  standards  document  goals  or  change  destinations. 

Several  improvement  models  and  standards  are  available.  Some  describe  practices  to  be  fol¬ 
lowed;  some  go  beyond  compliance  with  a  static  standard  and  emphasize  continuous  process 
and  quality  improvement  as  related  to  business  needs. 

Models  or  standards  are  often  part  of  an  assessment  or  improvement  method  that  may  include 
a  scheme  to  assess  status  or  compliance.  Guidelines  for  improvement  may  also  be  provided. 

Four  major  models  or  standards  are  outlined  in  this  section.  They  were  selected  based  on  their 
broad  recognition  and  current  usage,  or  (in  the  case  of  SPICE)  based  on  expected  impact  and 
usage  among  the  international  software  community.  The  Capability  Maturity  Model  for  Soft- 
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ware  and  SPICE  are  software  specific;  and  Malcolm  Baldrige  National  Quality  Award  and  ISO 
9001  may  be  used  in  software  or  other  types  of  organizations. 

Note  that  there  are  many  other  standards  or  models  or  awards  that  are  widely  recognized  and 
used,  and  references  are  provided  in  the  appendix. 

5.3.1  Capability  Maturity  Model  for  Software  (CMM) 

The  CMM  applies  process  management  and  quality  improvement  concepts  to  software  devel¬ 
opment  and  maintenance.  It  is  a  model  for  organizational  improvement  and  serves  as  a  guide 
for  evolving  toward  a  culture  of  engineering  excellence.  The  CMM  provides  the  underlying 
structure  for  software  appraisals — assessments  and  evaluations.  (See  Section  5.4.1)  It  offers 
a  staged  improvement  structure  based  on  the  quality  principles  of  Deming,  Juran,  and  Crosby 
[Paulk  93a],  [Paulk  93b]. 

Critical  concepts.  Software  process:  process  capability,  process 
performance,  process  maturity,  and  institutionalization. 

Structure  and  components  of  the  CMM.  Maturity  levels  indicate  process 
capability  and  contain  key  process  areas.  Key  process  areas  achieve  goals 
and  are  organized  by  common  features.  Common  features  address 
implementation  or  institutionalization  and  contain  key  practices.  Key  practices 
describe  infrastructure  or  activities  that  contribute  to  satisfying  the  goals  of 
that  key  process  area. 

The  maturity  levels.  Each  level  is  a  well-defined  evolutionary  plateau  toward 
achieving  a  mature  software  process;  each  level  builds  a  foundation  for 
succeeding  levels  to  use  to  implement  process  effectively  and  efficiently. 

Level  1:  Initial.  Process  is  informal  and  ad  hoc;  performance  is 
unpredictable. 

Level  2:  Repeatable.  Project  management  system  is  in  place; 
performance  is  repeatable;  and  there  is  a  disciplined  process. 

Level  3:  Defined.  Software  engineering  and  management  processes 
are  defined  and  integrated;  there  is  a  standard,  consistent  process. 

Level  4:  Managed.  Product  and  process  are  quantitatively  controlled; 
there  is  a  predictable  process. 

Level  5:  Optimizing.  Process  improvement  is  institutionalized;  there 
is  a  continuously  improving  process. 

The  key  process  areas.  (See  Section  4.7.2.) 

The  common  features.  (See  Section  6.2.2. 1.) 

5.3.2  Malcolm  Baldrige  National  Quality  Award 

This  award  recognizes  US  companies  that  excel  in  quality  management  and  quality  achieve¬ 
ment.  The  award  criteria  intend  to  help  companies  enhance  their  competitiveness  through  im- 
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proved  performance.  They  are  used  as  a  basis  for  submitting  an  award  application  and  are 
also  used  for  self-assessment,  planning,  training,  and  other  purposes  [MBNQA  93].  (See  also 
6.1.2.) 

Goals.  Customer  satisfaction;  customer  satisfaction  relative  to  competitors; 
customer  retention;  market  share  gain. 

Core  values  and  concepts.  Customer-driven  quality,  leadership,  continuous 
improvement,  employee  participation  and  development,  fast  response, 
design  quality  and  prevention,  long-range  outlook,  management  by  fact, 
partnership  development,  corporate  responsibility  and  citizenship. 

Measures  of  progress.  Product  and  service  quality;  productivity 
improvement;  waste  reduction/elimination,  supplier  quality. 

Award  criteria  framework.  Leadership;  information  and  analysis  (the  basis 
for  analysis  of  results,  process  improvement,  and  maintaining  alignment  of 
processes  with  business  strategy);  strategic  quality  planning  (integrating 
quality  and  operational  performance  requirements  with  business  strategy); 
human  resource  development  and  management;  management  of  process 
quality;  quality  and  operational  results;  customer  focus  and  satisfaction. 

5.3.3  ISO  9001 

The  ISO  9000  series  of  standards  deal  with  quality  management  systems  that  can  be  used  for 
external  quality  assurance  purposes.  ISO  9001  Quality  systems  -  Model  for  quality  assurance 
in  design/development,  production,  installation,  and  servicing  is  the  standard  pertinent  to  soft¬ 
ware  development  and  maintenance.  This  standard  specifies  quality  system  requirements  for 
use  where  a  contract  between  two  parties  requires  the  demonstration  of  a  supplier’s  capability 
to  design  and  supply  a  product  [ISO9001  87], 

ISO  9001  Quality  System  Requirements.  Management  responsibility; 
quality  system;  contract  review;  design  control;  document  control; 
purchasing;  purchaser-supplied  product;  product  identification  and 
traceability;  process  control;  inspection  and  testing;  inspection,  measuring, 
and  test  equipment;  inspection  and  test  status;  control  of  nonconforming 
product;  corrective  action;  handling,  storage,  packaging,  and  delivery;  quality 
records;  internal  quality  audits;  training;  servicing;  and  statistical  techniques. 

Certification.  ISO  9001  certification  provides  evidence  that  a  supplier  has 
reached  a  minimum  level  for  its  quality  management  system.  (See  also 
Section  6.1.2.) 

ISO  9000-3  provides  guidelines  for  the  application  of  ISO  9001  to  the  development,  supply, 
and  maintenance  of  software.  The  guidelines  are  intended  to  describe  suggested  controls  and 
methods  for  producing  software  that  meets  a  purchaser’s  requirements.  ISO  9000-3  structures 
the  ISO  9001  quality  system  requirements  into  three  quality  system  areas  (below)  and  re¬ 
names  and  elaborates  selected  clauses  [IS09000-3  91]. 

Quality  system  -  Framework.  Management  responsibility;  quality  system; 

Internal  quality  system  audits;  corrective  action. 
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Quality  system  -  Life-cycle  activities.  Contract  review;  purchaser’s 
requirements  specification;  development  planning;  quality  planning;  design 
and  implementation;  testing  and  validation;  acceptance;  replication,  delivery 
and  installation;  maintenance. 

Quality  system  -  Supporting  activities.  Configuration  management; 
document  control;  quality  records;  measurement;  rules,  practices  and 
conventions;  tools  and  techniques;  purchasing;  included  software  product; 
training. 

5.3.4  Software  Process  improvement  and  Capability  Determination 
(SPICE)  Process  Framework 

SPICE  is  a  proposed  international  standard  that  provides  an  assessment  method  whose  re¬ 
sults  can  be  used  for  process  improvement  or  for  process  capability  determination.  The  as¬ 
sessment  method  (See  Section  5.4.2.)  rates  processes  against  the  process  framework 
defined  in  the  Baseline  Practices  Guide  (BPG).  That  framework  provides  a  roadmap  for  im¬ 
provement. 

The  BPG  defines  practices  and  processes  which  should  be  implemented  to  establish  and  im¬ 
prove  an  organization’s  software  capabilities.  Practices  are  organized  using  an  architecture 
which  provides  two  different  categorizations  of  the  practices  [SPICE-BPG  94]. 

SPICE  Architecture:  Grouping  by  type  of  activity.  A  process  category 
addresses  the  same  general  area  of  activity  and  contains  processes;  a 
process  achieves  a  purpose  and  contains  activities;  a  base  practice  is  an 
activity  that  addresses  the  purpose  of  a  particular  process.  (See  Section  4.7.1 
for  a  description  of  the  process  categories.) 

SPICE  Architecture:  Grouping  by  type  of  implementation  or 
institutionalization  activity.  A  capability  level  contains  common  features 
that  work  together  to  provide  a  major  enhancement  in  the  capability  to 
perform  a  process;  a  common  feature  contains  practices  that  address  the 
same  aspect  of  process  implementation  or  institutionalization;  a  generic 
practice  is  an  implementation  or  institutionalization  practice  that  enhances  the 
capability  to  perform  any  process.  (See  Section  6.2.2.2  for  a  description  of  the 
common  features.) 

A  process  contains  both  base  practices  and  generic  practices  and  may  be 
assessed  in  terms  of  capability  levels,  common  features,  or  generic  practices. 

The  Capability  Levels.  Provide  an  improvement  roadmap  for  an 
organization  to  improve  any  specific  process. 

Level  0:  Not-Performed.  General  failure  to  perform  the  base  practices  of 
the  process. 

Level  1 :  Performed-informally.  Base  practices  of  the  process  are  gen¬ 
erally  performed. 

Level  2:  Planned-and-Tracked.  Performance  of  the  base  practices  of 
the  process  is  planned  and  tracked. 
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Level  3:  Well-Defined.  Base  practices  are  performed  according  to  a  well- 
defined  process  using  approved,  tailored  versions  of  the  standard  docu¬ 
mented  process. 

Level  4:  Quantitatively-Controlled.  Detailed  measures  of  performance 
are  collected  and  analyzed. 

Level  5:  Continuously-Improving.  Quantitative  process  effectiveness 
and  efficiency  goals  (targets)  for  performance  are  established  based  on 
business  goals  of  the  organization;  continuous  process  improvement 
against  these  goals  is  enabled. 

5.4  Process  Appraisal 

Process  appraisals  are  carried  out  to  characterize  current  practices  in  an  organization.  They 
rate  an  organization’s  process  maturity  against  a  reference  model. 

There  are  many  possible  types  of  appraisals  with  different  goals,  uses,  methods,  and  support¬ 
ing  tools.  Appraisals  may  provide  information  to  help  customers  select  software  suppliers,  to 
guide  suppliers  with  internal  process  improvement  efforts,  or  to  guide  joint  customer/supplier 
process  improvement  and/or  risk  management  efforts  [Masters  95]. 

Assessments  for  the  purposes  of  award  application  (such  as  applying  for  the  Malcolm  Baldrige 
National  Quality  Award)  or  for  certification  (such  as  seeking  IS09000  certification)  may  also 
be  used  to  characterize  current  practice  in  relation  to  those  standards.  These  may  be  part  of 
an  organization’s  process  improvement  strategy.  (See  Section  6.1.2.) 

Here  we  present  appraisal  methods  pertaining  more  specifically  to  software  process  appraisal. 

5.4.1  CMM-Based  Appraisals 

Several  appraisal  methods  are  based  on  the  CMM  for  software  as  a  reference  model. 

5.4.1. 1  CMM  Appraisal  Framework  (CAF) 

The  CMM  appraisal  framework  (CAF)  provides  a  framework  for  rating  the  process  maturity  of 
an  organization  against  the  CMM  for  software.  It  includes  a  generic  appraisal  architecture  and 
it  defines  requirements  for  developing  CAF  compliant  appraisal  methods.  The  primary  activi¬ 
ties  of  a  CAF  compliant  appraisal  method  are  the  following  [Masters  95]: 

Plan  and  prepare  for  appraisal.  Analyze  requirements,  select  and  prepare 
team,  select  and  prepare  participants,  develop  appraisal  plan. 

Conduct  appraisal.  Collect  and  record  data,  consolidate  data,  make  rating 
judgements 

Report  results.  Report  appraisal  results,  protect  confidentiality,  preserve 
records. 
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5.4.1 .2  CMM-Based  Appraisal  for  Internal  Process  Improvement  (CBA IPI) 

CBA  IPI  is  an  SEI  method  for  conducting  software  assessments.  It  contains  rules  for  collecting 
information,  assessing  reliability  of  the  information,  making  judgements  about  the  current  state 
of  the  process,  and  reporting  the  results.  The  method  identifies  an  organization’s  strengths 
and  weaknesses  to  help  build  an  improvement  program  action  plan  [CBA  IPI  95]. 

5.4.1 .3  Software  Capability  Evaluation  (SCE) 

A  CMM-based  software  capability  evaluation  (SCE)  is  an  independent  evaluation  of  an  orga¬ 
nization’s  software  process  as  related  to  a  particular  acquisition.  An  acquirer  uses  an  SCE  to 
help  determine  a  supplier’s  ability  to  produce  a  particular  product  [SCE:SPA  92],  [CBA  Project 
94]. 

5.4.1. 4  Software  Process  Assessment  (SPA) 

A  CMM-based  software  process  assessment  (SPA)  is  an  in-house  determination  primarily  of 
weaknesses  of  the  software  process  in  an  organization  as  a  whole.  An  organization  can 
choose  an  SPA  as  part  of  an  overall  process  improvement  program  [SCE:SPA  92],  [Olsen  89]. 

5.4.1. 5  Interim  Profile 

An  interim  profile  is  a  CMM-based  method  to  rapidly  measure  an  organization’s  software  en¬ 
gineering  process  maturity  between  software  process  assessments.  Activities  of  the  method 
include:  logistics  and  setup,  initial  data  collection  and  analysis,  review  and  revision  of  draft 
project  profiles,  distribution  of  final  profiles,  and  audit  of  the  interim  profile  process  [Whitney 
94]. 

5.4.2  SPICE  Process  Assessment 

In  the  SPICE  standard,  process  assessment  is  used  to  understand  an  organizational  unit’s 
current  processes.  The  reference  model  used  is  the  SPICE  Baseline  Practices  Guide. 

Assessment  is  initiated  by  a  sponsor’s  desire  for  process  improvement  or  by  an  acquirer’s 
wish  to  evaluate  the  capability  of  a  supplier.  In  each  case  the  initiator  determines  the  assess¬ 
ment  purpose,  scope,  constraints,  responsibilities,  and  extended  process  definitions  [SPICE- 
PAG  94]. 


Assessment  approaches.  Self-assessment  (for  internal  improvement), 
team-based,  tool-based;  independent  assessment. 

Assessment  stages.  Review  assessment  input,  select  process  instances, 
prepare  for  assessment,  collect  and  verify  information,  determine  actual 
ratings,  determine  derived  ratings,  validate  ratings,  present  output. 

Success  factors.  Commitment,  motivation,  confidentiality,  relevance, 
credibility. 

Assessment  instrument.  A  probe  to  capture,  collate,  and  formalize  process 
information. 
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5.5  Improvement  Approaches:  Organizational  Level 

A  maturity  model  or  a  quality  standard  can  provide  goals  for  improvement,  but  how  do  you  go 
about  improving? 

This  section  describes  a  variety  of  improvement  approaches  that  delineate  various  phases, 
stages,  or  activities  required  for  process  improvement  at  the  organizational  level.  Knowledge 
of  various  approaches  enables  organizations  to  be  familiar  with  steps,  to  compare  and  con¬ 
trast  approaches,  analyze  parts,  synthesize  or  tailor  an  approach  to  meet  circumstance,  or  de¬ 
rive  a  new  approach. 

These  approaches  vary  in  scope.  Some  encompass  organizational  transformation  issues 
such  as  management  structures,  culture  change,  and  environmental  factors;  others  focus  on 
a  narrower  view  of  process  improvement. 

All  of  the  approaches  are  top-down  approaches  emphasizing  senior  management  sponsor¬ 
ship  and  organization-wide  planning.  All  of  the  approaches  lead  to  selection  and  improvement 
of  specific  processes.  (Approaches  for  improvement  at  the  process  level  are  discussed  in  the 
next  section.) 

Most  approaches  are  generic  and  can  be  used  to  pursue  any  improvement  goals.  Note  that 
the  approaches  described  here  are  examples  of  process  improvement  strategies  that  are  in 
use  or  proposed  as  standards.  Many  other  approaches  exist;  several  are  referenced  in  the  Ap¬ 
pendix. 

To  distinguish  between  activity  levels,  sometimes  organizational  improvement  efforts  are 
called  process  improvement  programs,  while  spin-off  activities  at  the  process  level  may  be 
called  process  improvement  projects. 

5.5.1  The  Shewhart  (Deming)  Cycle 

This  classical  management  strategy  provides  a  systematic  approach  to  controlling  and  im¬ 
proving  quality  by  studying  a  process  and  analyzing  its  performance  through  four  steps:  plan, 
do,  check,  and  act.  Deming  further  developed  this  approach  in  his  process  improvement 
work.This  strategy  can  be  applied  at  various  process  levels  and  several  improvement  ap¬ 
proaches  are  derived  from  this  basic  cycle  [Shewhart  31],  [Deming  86]. 

Plan.  Define  the  problem;  state  improvement  objectives. 

Do.  Identify  possible  causes  of  the  problem;  establish  baselines;  test  change. 

Check.  Evaluate;  collect  data. 

Act.  Determine  effectiveness;  implement  system  change. 
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5.5.2  An  Integrated  Approach  to  Software  Process  Improvement  (The 
IDEALSM  Approach) 

This  SEI  software  process  improvement  approach  describes  phases  and  activities  entailed  in 
software  process  improvement.  The  five  phases  are  Initiate,  Diagnose,  Establish,  Act,  Lever¬ 
age  (hence,  IDEAL)  [Radice  94]. 

Initiating  phase.  Stimulus  for  improvement;  set  context  and  establish 
sponsorship;  establish  improvement  infrastructure. 

Diagnosing  phase.  Appraise  and  characterize  current  practice;  develop 
recommendations  and  document  phase  results. 

Establishing  phase.  Set  strategy  and  priorities;  establish  process  action 
teams;  plan  actions. 

Acting  phase.  Define  processes  and  measures;  plan  and  execute  pilots; 
plan,  execute,  and  track  installation. 

Leveraging  phase.  Document  and  analyze  lessons;  revise  organizational 
approach. 

5.5.3  Software  Process  Improvement  (SPI)  Roadmap 

The  software  process  improvement  (SPI)  roadmap  is  a  long-range,  integrated  plan  for  initiat¬ 
ing  and  managing  a  SPI  program.  It  provides  a  phased,  generic  approach  addressing  both 
strategic  and  tactical  activity  levels.  This  approach  was  developed  as  the  result  of  a  strategic 
collaboration  between  the  SEI  and  Hewlett  Packard  Company.  It  is  based  on  the  work  of  sev¬ 
eral  SEI  projects,  and  the  concepts  were  proven  with  SEI  clients  and  internal  Hewlett  Packard 
clients  [McFeeley  94]. 

SPI  roadmap  phases.  Initiating  SPI;  baselining  (understanding  the  current 
processes  and  opportunities);  implementing  (developing  and  sustaining 
improvements). 

Strategic  level  activities.  Initiate  SPI;  manage  the  SPI  program;  build  SPI 
strategy. 

Tactical  level  activities.  Baseline  current  state;  develop  improvements; 
deploy  improvements. 

SPI  infrastructure.  Management  Steering  Group  (MSG);  Software 
Engineering  Process  Group  (SEPG);  process  action  teams  (PATs). 

5.5.4  The  Software  Engineering  Improvement  Method 

The  software  engineering  improvement  method  is  a  systematic  method  of  integrated  software 
engineering  improvement  that  the  SEI  is  employing  with  pilot  customers.  The  objective  is  to 
provide  a  systematic  means  for  achieving  software  engineering  improvement  over  time.  The 
premise  is  that  for  a  given  organization,  desired  software  engineering  practices,  technologies, 


*■  IDEAL  is  a  service  mark  of  Carnegie  Mellon  University. 
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and  organizational  capabilities  can  be  defined  as  goal  states  to  be  achieved  along  with  the  pro¬ 
cesses,  methods,  and  organizational  infrastructure  necessary  to  achieve  them.  Once  goal 
states  are  defined,  the  way  to  attain  them  can  be  described  as  a  software  process  definition, 
and  managed  as  a  well-defined  software  engineering  project  [SEIM  94]. 

Define  software  engineering  improvement  framework.  Describe  vision, 
define  software  engineering  goals  linked  to  organizational  goals  and  tailored 
to  software  engineering  capabilities;  identify  anticipated  technology  and 
process  needs;  identify  appropriate  methods  to  achieve  specified  goals. 

Form  software  engineering  improvement  process  definition.  Build  on  the 
defined  improvement  framework;  decide  on  sequence  of  methods  to  attain 
goals;  define  conditions  for  starting  improvement  activities  and  criteria  for 
completeness;  identify  types  of  agents  who  will  play  a  role  in  the 
improvements. 

Form  software  engineering  improvement  project  plan.  Attach  schedules, 
resources,  people  to  the  software  engineering  improvement  process 
definition. 

Manage  the  improvement  project  plan.  Create  guidelines;  ensure  adoption 
of  specified  organizational  changes,  technologies,  and  processes  on  a  just- 
in-time  basis;  monitor  and  verify  results;  communicate  status,  results,  and 
lessons  learned;  adjust  priorities  for  ongoing  or  next  improvement  activities. 

5.5.5  SEI  Leadership  Series  Strategy  for  Process  Improvement 

The  SEI  Leadership  Series  of  courses  offers  a  strategy  for  process  improvement  including  the 
following  10  points  [SEI  LSC]. 

Where  are  you  now.  Process  definition  baseline;  metrics  baseline;  process 
assessment  baseline. 

Where  are  you  going.  Goal  Setting. 

How  do  you  get  there.  Quality  improvement;  productivity  improvement;  risk 
management  improvement. 

Make  it  happen.  Training  and  people  development;  process  organization; 
implementation  plan. 

5.5.6  Advanced  Quality  System  (AQS) 

Boeing’s  Advanced  Quality  System  (AQS)  for  software  provides  a  documented  approach  to 
meeting  progressively  higher  process  and  product  quality  standards  [Boeing  94],  This  ap¬ 
proach  is  tied  to  measuring  improvement  in  accordance  with  the  CMM  for  software,  although 
it  may  also  be  used  in  connection  with  other  models  which  have  equivalent  goals.  AQS  is  used 
to  ensure  suppliers  are  committed  to  the  continuous  improvement  of  software  processes  and 
products.  There  are  four  stages  that  are  tied  to  the  maturity  level  of  the  supplier. 
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Stage  I  (for  organizations  at  CMM  maturity  Level  1  or  2).  Prepare  process 
improvement  commitment,  conduct  assessment,  prepare  process 
improvement  plan. 

Stage  II  (for  organizations  at  CMM  maturity  Level  1  or  2).  Implement  process 
improvement  plan. 

Stage  III  (for  organizations  at  CMM  Level  3).  Prepare  product  quality 
measurement  plan,  implement  product  quality  measurement  plan. 

Stage  IV  (for  organizations  at  CMM  Level  4  or  5).  Prepare  product  quality 
targets  plan,  implement  product  quality  targets  plan,  re-evaluate  and  maintain 
targets. 

5.5.7  Managing  Process  Improvement 

Software  Productivity  Consortium’s  Managing  Process  Improvement  [SPC  94]  is  a  compre¬ 
hensive  approach  for  initiating  and  sustaining  a  process  improvement  program.  The  approach 
addresses  five  organizational  subsystems  (strategic,  technological,  human/cultural,  structural, 
and  managerial)  with  special  focus  on  improving  the  managerial  and  technological  areas.  Five 
steps  are  carried  out  iteratively  to  progress  towards  improvement  objectives. 

Understand  context.  Build/reinforce  sponsorship  and  foundation, 
define/update  improvement  strategies,  assess/understand  process,  review 
context. 

Analyze  risks  and  select  strategy.  Analyze  and  resolve  risks,  select 
improvement  strategy,  commit  to  strategy. 

Plan  improvement.  Define/update  action  plan,  commit  to  action  plan. 

Implement  improvements.  Implement,  manage  and  monitor,  review 
process  improvements. 

Review  and  update.  Review  progress,  define/update  program  plan,  commit 
to  proceed. 

5.5.8  SPICE  Process  Improvement  Guide 

The  SPICE  Process  Improvement  Guide  provides  a  complete  framework  for  software  process 
improvement  including  a  methodology  for  software  process  improvement  and  guidance  on  the 
following  topics:  using  SPICE  assessment  results,  how  to  measure  software  process  effective¬ 
ness  and  improvement  effectiveness,  how  to  use  business  goals  to  drive  identification  of  im¬ 
provement  actions,  how  to  use  the  SPICE  Baseline  Practices  Guide  as  a  roadmap  for 
improvement,  and  how  to  consider  people  issues  and  how  to  deal  with  management  issues 
for  software  process  improvement  [SPICE-PIG  94]. 

The  software  process  improvement  methodology.  Examine 
organization’s  need;  initiate  process  improvement;  prepare  and  conduct 
SPICE  process  assessment;  analyze  assessment  results  and  derive  action 
plan;  implement  improvements;  confirm/validate  improvements;  sustain 
improvement  goals;  monitor  performance/continue  process  improvement. 
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5.5.9  ISO  9004-4  Guidelines 

ISO  9004-4  Quality  management  and  quality  system  elements  -  Part  4:  Guidelines  for  quality 
improvement  provides  the  following  guidelines  for  implementing  continuous  quality  improve¬ 
ment  within  an  organization  [IS09004-4  93]. 

Managing  for  quality  improvement.  Organizing  for  quality  improvement; 
planning  for  quality  improvement,  measuring  quality  improvement,  reviewing 
quality-improvement  activities. 

Methodology  for  quality  improvement.  Involving  the  whole  organization; 
initiating  quality  improvement  projects  or  activities;  investigating  possible 
causes;  establishing  cause-and-effect  relationships;  taking  preventive  or 
corrective  actions;  confirming  the  improvement;  sustaining  the  gains; 
continuing  the  improvement. 


5.6  Improvement  Approaches:  Process  Level 

Improvement  at  the  process  level  addresses  positive  change  in  the  way  the  work  is  accom¬ 
plished.  It  includes  refining  workflows,  eliminating  effort  that  does  not  add  value,  reducing  vari¬ 
ation,  and  controlling  and  improving  the  process. 

The  improvement  of  a  specific  process  may  be  initiated  in  the  context  of  an  organizational  im¬ 
provement  effort  that  has  targeted  that  process  for  improvement.  Alternately,  a  project  or  team 
may  independently  decide  to  improve  its  processes.  This  may  lead  to  broader  process  im¬ 
provement  in  a  middle-out  way. 

There  are  several  improvement  models  at  this  level,  and  three  of  them  are  described  below. 
Others  are  referenced  in  the  Appendix. 

5.6.1  Model  of  Progress:  Joiner  Associates 

This  approach  shows  the  general  progression  of  events  in  process  improvement  teams  and 
includes  a  model  of  progress  and  a  plan  for  process  improvement. 

Model  of  progress.  Clarify  goals;  educate  and  build  the  team;  investigate  the 
process;  analyze  data  and  seek  solutions;  take  appropriate  action;  closure. 

Plan  for  process  improvement.  Understand  the  process;  eliminate  errors; 
remove  slack;  reduce  variation;  plan  for  continuous  improvement  [Scholtes 
88]. 

5.6.2  Logistics  Management  Institute — Continuous  Improvement 
Process:  Process-Improvement  Model 

This  model  incorporates  the  Plan-Do-Check-Act  approach  and  also  addresses  the  need  to 
standardize  processes  [Mansir  89], 

Set  the  stage  for  process  improvement.  Select  the  team,  train  team 
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Select  a  process  to  improve.  Identify  opportunities,  prioritize,  choose, 
identify  major  problems  and  root  causes,  identify  measurement  points. 

Define  the  process.  Customers,  suppliers,  how  process  currently 
performed,  measures. 

Standardize  the  process.  Institutionalize  current  best  way  to  perform  that 
process:  Standardize-Do-Check-Act;  train;  assess  and  eliminate  causes  of 
deviation  from  standard. 

Tighten  up  the  process.  Ensure  process  meets  requirements,  establish 
data  collection  system. 

Improve  the  process.  Plan-Do-Check-Act. 

Assess  improvement  performance.  Document  improved  performance 

5.6.3  Quality  Improvement  Process  /  Problem-Solving  Process:  Xerox 

The  Leadership  Through  Quality  (LTQ)  approach  to  process  improvement  includes  two  pro¬ 
cesses  for  improvement.  The  Quality  Improvement  Process  (QIP)  is  a  model  for  changing 
work  processes  to  improve  quality;  the  Problem  Solving  Process  (PSP)  is  part  of  the  QIP,  and 
is  used  to  find  solutions  to  problems  that  arise  during  the  QIP  [PSP  91],  [QIP  91]. 

Quality  Improvement  Process 

Planning  for  quality.  Identify  output;  identify  customer;  identify  customer 
requirements;  translate  requirements  into  supplier  specifications. 

Organizing  for  quality.  Identify  steps  in  work  process;  select  measure¬ 
ments;  determine  process  capability. 

Monitoring  for  quality.  Evaluate  results;  recycle. 

Problem  Solving  Process 

Identify  and  select  problem;  analyze  problem;  generate  potential  solu¬ 
tions;  select  and  plan  the  solution;  implement  the  solution;  evaluate  the 
solution. 

5.7  Improvement  Approaches:  Individual  Level 

Individual  improvement  approaches  are  techniques  for  self  improvement.  They  may  be  ap¬ 
plied  within  the  context  of  a  broader  improvement  effort,  or  simply  at  an  individual  level.  They 
may  be  used  to  initiate  broader  process  improvement  in  a  bottom-up  way.  These  approaches 
offer  ways  for  anyone  to  apply  discipline  to  everyday  activities. 

Two  examples  are  described  below.  (See  also  7.3.5  and  9.3.) 

5.7.1  Personal  Software  Process  (PSP) 

The  personal  software  process  (PSP)  is  a  paradigm  suggested  by  Watts  Humphrey.  Its  pur¬ 
pose  is  to  improve  individual  software  engineers  productivity,  and  its  approach  is  based  on  a 
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disciplined  application  of  software  development  process  to  individual  and  small  teams.  PSP 
helps  individual  software  engineers  improve  their  skills,  better  manage  and  control  their  work, 
establish  personal  goals  for  their  processes,  define  the  methods  they  will  use,  measure  their 
work,  and  analyze  the  results  [Humphrey  94a]. 

PSP  paradigm.  Each  practitioner  establishes  personal  process  goals, 
defines  the  methods  to  be  used,  measures  the  work  done,  analyzes  the  result 
obtained,  and  based  on  the  analysis  adjusts  the  method. 

PSP  stages.  PSP  takes  the  practitioners  through  a  set  of  evolutionary  stages 
called  the  Baseline  Process  (PSPO),  the  Personal  Planner  Process  (PSP1), 
Personal  Error  Management  (PSP2),  Personal  Design  Principles  (PSP3),  the 
Cycle  Personal  Process  (PSP4),  and  the  Team  Software  Process  (TSP). 

5.7.2  Logistics  Management  Institute — Continuous  Improvement 
Process:  Personal-Improvement  Model 

This  applies  the  LMI  CIP  Transformation  Model  to  individual  improvement  efforts.  It  involves 
establishing  a  vision  for  individual  improvement,  enabling  that  effort,  focusing  on  continuous 
improvement,  and  improving  through  self-evaluation  [Mansir  89]. 

Envision  personal  improvement.  Self-awareness:  relationships  with  your 
customers  and  suppliers. 

Enable  personal  improvement.  Self  education,  learn  process  improvement 
concepts,  principles,  tools. 

Focus  on  improvement.  Establish  goals,  align  activities  with  goals,  create 
time  for  improvement  activities,  commitment. 

Improve  your  job.  Define  your  processes,  remove  complexity. 

Improve  yourself.  Commitment  to  personal  improvement,  communicate, 
remove  barriers. 

Help  others  improve.  Train  and  coach  others,  encourage  others. 

Evaluate  your  improvement  progress.  Measure  and  document  your 
performance:  reward  yourself. 
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6  Process  and  Process  Improvement  Management 


“The  objectives  of  software  process  management  are  to  produce  products 
according  to  plan  while  simultaneously  improving  the  organization’s  capability 
to  produce  better  products." — Watts  Humphrey 

Section  4  described  general  process  concepts  and  presented  examples  of  specific  software 
engineering  processes  that  can  be  improved.  Then  Section  5  presented  process  improvement 
concepts,  models,  standards,  and  approaches  to  improving  those  processes.  These  are  what 
one  must  know  as  one  embarks  on  process  improvement. 

We  now  describe  what  one  might  do  in  the  application  of  those  concepts.  We  extract  major 
activities  carried  out  during  process  improvement  and  give  examples  of  knowledge  and  skills 
used  in  those  activities.  Process  improvement  skills  are  further  described  in  later  sections. 

Should  improvements  be  made  in  a  top-down,  middle-out,  or  bottom-up  way?  It  depends  on 
many  things  such  as  context,  circumstance,  and  culture.  Improvement  may  be  carried  out  in 
a  parallel  way  at  all  levels;  the  efforts  are  highly  interrelated.  As  far  as  initiating  process  im¬ 
provement,  we  offer  the  following  view: 

“In  one  sense,  it  does  not  matter  where  an  organization  begins  to  focus  on 
improvement;  the  important  decision  is  making  the  commitment  to  improve.” 

— Betty  Deimel  [Deimel  94b] 

In  this  section  we  describe  process  improvement  at  two  levels:  organizational-level  process 
improvement  activities,  which  we  call  process  improvement  management,  and  activities  to 
manage  and  improve  a  single  process,  which  we  call  process  management.  We  devote  the 
last  section  to  some  topics  in  organizational  process  management. 

6.1  Process  Improvement  Management 

In  this  section  we  describe  the  major  activities  in  carrying  out  a  top-down  improvement  effort 
at  the  organizational  level.  These  are  presented  in  a  generic  framework  of  activity  areas  based 
on  the  commonalities  among  the  approaches  in  Section  5.5. 

6.1.1  Initiating  Process  Improvement 

Process  improvement  occurs  within  the  context  of  an  organization’s  strategic  plans  and  busi¬ 
ness  objectives. 

6.1 .1 .1  Recognizing  Need  for  Improvement 

Process  improvement  requires  some  stimulus  to  initiate  the  improvement  effort;  these  stimuli 
derive  from  business  needs.  It  is  important  to  identify  risk  factors  such  as  the  risk  of  not  under¬ 
taking  improvement  or  the  risk  of  failure  in  improvement  undertaking. 
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Internal  drivers.  Desire  to  increase  competitiveness:  cost  reduction, 
achievement  of  customer  quality  goals,  reduction  of  time  to  market, 
predictability;  desire  to  attain  corporate  vision,  adopt  new  values;  gaps 
between  current  and  desired  capability. 

External  requirements.  Contract  requirements,  product  requirements, 
certification  requirements,  industry  benchmark  requirements,  customer 
feedback,  market  decline,  gaps  between  current  performance  and 
customer/market  expectations;  offshore  competition;  policy  changes. 

Knowledge  and  skills:  market  research,  environmental  awareness,  risk 
assessment,  benchmarking,  customer  value  determination. 

6.1 .1 .2  Visioning  and  Goal  Setting 

Improvement  is  driven  by  a  vision  of  what  is  trying  to  be  created  by  the  improvement  effort. 

Visioning.  Deriving  and  communicating  a  vision;  search  conferences  to 
derive  a  shared  vision;  determining  the  corporate  mission. 

Evaluation  and  selection.  Evaluating  improvement  models  and  standards 
vs.  business  needs;  selecting  or  tailoring  the  improvement  model/standard. 

Goal  setting.  Setting  improvement  goals  on  quality,  productivity,  risk 
management,  maturity  level;  setting  goals  that  are  quantitative,  reasonably 
aggressive,  achievable,  measurable,  and  visible;  relating  rewards  to  goals. 

Critical  success  factors.  Identifying  those  actions  that  will  enable  an 
enterprise  to  achieve  its  goals. 

Communicating  goals.  Communicating  authentically,  so  that  goals  are  seen 
as  achievable,  to  everyone,  and  so  that  the  goals  are  related  to  the  personal 
objectives  of  others. 

Knowledge  and  skills.  Understanding  improvement  models  and  standards, 
understanding  business  needs,  cost/benefit  analysis,  feasibility  studies,  quality 
measurement,  deriving  process  goals  from  business  needs  or  strategies,  costs 
of  low  quality,  how  to  document  and  substantiate  return  on  investment, 
visioning  and  goal  setting;  knowledge  of  the  business/customers, 
communication. 

6.1 .1 .3  Planning  for  Process  Improvement 

Strategic  plans  document  the  strategy  to  guide  the  organization  and  the  process  improvement 
program  for  the  next  three  to  five  years. 

Evaluation  and  selection.  Evaluating  improvement  approaches  vs.  goals 
and  organizational  constraints/situation;  selecting  or  tailoring  the  approach. 
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Strategic  planning.  Deriving  the  strategic  plan  to  meet  business  needs; 
linking  software  process  improvement  to  the  organization’s  strategic  direction 
and  objectives;  process  improvement  planning  and  estimation;  resources, 
activities,  schedule,  milestones,  review  points,  risks,  reporting;  software 
process  improvement  as  a  strategic  initiative;  tying  vision  and  goals  to 
strategic  plan. 

Communicating  the  plan. 

Knowledge  and  skills:  software  process  improvement  planning  and  estimating, 
understanding  improvement  objectives  and  approaches,  communication. 

6.1 .1 .4  Organizing  for  Process  Improvement 

There  must  be  a  basic  organizational  infrastructure  in  place. 

Basic  improvement  infrastructure.  Management  steering  committee, 
process  group  (Software  Engineering  Process  Group),  working  groups 
(process  action  teams);  roles,  responsibilities,  charters;  relationships; 
reporting  structures. 

Establishing  commitment.  Building  executive  support,  sponsorship, 
building  the  infrastructure,  estimating  and  assigning  resources  and 
responsibilities,  funding  and  empowering. 

Roles  in  process  improvement.  Agents,  appraisal  team,  champions,  line 
managers,  participants,  pilot  project  personnel,  process  action  teams, 
software  practitioners,  sponsors,  support  organizations. 

Knowledge  and  skills:  consulting  skills,  contracting,  negotiating,  teamwork 
skills,  organizational  development  skills. 

6.1.2  Establishing  Baselines 

“If  you  don’t  know  where  you  are,  a  map  won’t  help.”  — Watts  Humphrey 

Baselines  describe  the  way  an  organization  currently  performs  its  business  and  detail  the 
starting  point  for  measuring  improvement.  Baselines  provides  a  systematic  and  thorough  way 
to  understand  and  document  current  status. 

The  organization  must  determine  what  to  baseline  and  how  often  to  do  it.  For  internal  process 
improvement,  process  appraisals  may  be  complemented  with  measurement  or  risk  assess¬ 
ment.  Contract  requirements,  certification,  award  aspirations,  or  customer  evaluation  needs 
may  determine  the  baselining  methods. 

6.1 .2.1  Process  Appraisal 

Process  appraisals  are  used  to  gather  data  about  process  issues,  to  build  consensus  among 
staff  and  management  concerning  issues  and  priorities,  and  to  motivate  improvement.  There 
are  a  variety  of  appraisal  methods  used  in  the  context  of  different  reference  models,  and  they 
are  used  for  various  purposes  as  described  in  Section  5.4.  Most  are  based  on  questionnaires 
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and  interviews,  but  automated  tools  may  be  available.  Assessments  result  in  a  report  describ¬ 
ing  strengths,  weaknesses,  and  recommendations  for  addressing  weak  areas. 

Assessment  principles  are  similar:  secure  sponsorship,  start  with  a  process  framework,  ob¬ 
serve  strict  confidentiality,  involve  senior  management,  approach  assessment  collaboratively, 
and  focus  on  action. 

Appraisal  methods.  CMM-based  appraisal  methods;  SPICE  conformant 
assessment,  risk  assessment. 

Complementary  techniques.  Special  meetings,  search  conferences,  focus 
groups,  surveys,  interviews,  routine  postmortems,  lessons  learned  activities. 

Evaluation  and  selection.  Choosing  an  appraisal  method;  criteria  and 
considerations;  tailoring  or  developing  an  appraisal  method;  constructing 
assessment  instruments;  common  rating  frameworks. 

Preparing  for  assessment.  Identifying  sponsor;  selecting  assessors  (third- 
party,  in-house,  assisted  assessment);  determining  purpose,  scope, 
constraints,  responsibilities;  selecting  projects/areas/processes  for 
assessment. 

Conducting  the  appraisal.  Data  gathering,  rating,  scoring,  profiling, 
validating,  reporting  on  findings. 

Assessors.  Skills  and  training. 

Knowledge  and  skills:  appraisal  methods,  assessment  procedures,  data 
gathering,  analysis,  sampling,  teamwork,  reporting,  communication,  risk 
assessment. 

6.1 .2.2  Measurement  Baselining 

A  measurement  baseline  identifies  the  current  measurement  data  that  is  available  and  sets  up 
basic  measurement  methods  to  be  used. 

Measurement  goals.  Define  goals,  outline  measures,  define  measures, 
define  data  collection,  analysis,  and  validation  procedures,  establish  initial 
measurement  baseline  (initial  level  of  business  and  process  metrics  against 
which  to  measure  progress). 

Metrics  baseline.  Some  example  basic  metrics:  lines  of  code,  function 
points,  person-months,  dollars,  elapsed  time,  defects,  customer  satisfaction 
indices;  predictability  (risk);  historical  and  ongoing  data. 

Knowledge  and  skills:  measurement,  data  collection  and  analysis. 

6.1. 2.3  Developing  an  Organizational  Risk  Profile 

An  organizational  risk  profile  will  help  determine  organizational  risks  to  software  process  im¬ 
provement. 
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Risk  management  improvement.  Establish  a  risk  management  action  plan: 
identify,  analyze,  plan,  track,  control,  and  communicate. 

Climate  assessment.  Identify  barriers  and  leverage  points  across  the 
organization  that  will  affect  the  process  improvement  program. 

Knowledge  and  skills:  risk  assessment,  risk  management,  change 
management. 

6.1. 2.4  ISO  Certification 

If  an  organization  is  seeking  ISO  9000  certification,  baselining  takes  a  different  form  [Spizizen 
92]. 

Assessment  approaches.  Selecting  the  quality  assessment  approach  (self- 
assessment,  second-party  customer  audit,  third  party  registration);  selecting 
the  registrar;  periodic  surveillance;  re-audits. 

Audit  process.  Appraisal  of  quality  manual,  assessment  to  evaluate 
conformance  to  documented  procedures,  presentation  of  findings  with  any 
recommendations  for  corrective  action. 

6.1 .2.5  Malcolm  Baldrige  National  Quality  Award  Assessment 

Applying  for  an  award  such  as  the  Malcolm  Baldrige  National  Quality  award  is  another  ap¬ 
proach  to  baselining  [MBNQA  93]. 

Assessment  system.  Criteria  are  a  set  of  28  basic,  interrelated,  results- 
oriented  requirements  (examination  items);  scoring  guidelines  that  define 
assessment  dimensions  (approach,  deployment,  and  results);  and  key 
factors  used  in  assessment  relative  to  each  dimension. 

Award  examination.  Applicant  prepares  application  package  including 
information  and  data  on  improvement  processes  and  results;  uses  of  the 
award  criteria  for  self-assessment. 

Application  review.  Independent  review  and  evaluation  by  Board  of 
Examiners,  consensus  review  and  evaluation,  site  visits,  judges’  review  and 
recommendations,  feedback  to  applicants. 

6.1.3  Setting  Priorities 

After  baselines  have  been  established,  assessment  results  must  be  analyzed  to  derive  prior¬ 
ities  and  action  plans.  Priorities  will  depend  on  business  objectives  and  the  improvement  stan¬ 
dard  or  model  selected. 

For  example,  an  organization  may  follow  the  CMM  approach  towards  establishing  organiza¬ 
tional  capability  and  proceed  according  to  the  ordering  of  processes  at  the  maturity  levels.  Or¬ 
ganizational  process  improvement  may  also  be  achieved  by  setting  priorities  for  improving  the 
processes  in  the  Organization  Process  category  of  the  SPICE  BPG. 
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The  processes  to  improve  may  be  organizational  or  project  level  processes,  supporting  pro¬ 
cesses,  product  engineering  processes,  or  any  processes  deemed  central  to  business  needs. 

Prioritization.  Identify  and  prioritize  improvement  areas. 

Goal  setting.  Identify  improvement  goals  and  set  targets  (define  quantitative 
goals  for  each  priority  area;  devise  suitable  metrics  to  measure  achievement 
of  these  goals;  set  appropriate  target  values  for  these  metrics,  considering 
risks;  ensure  consistency  with  business  strategies  and  goals). 

Action  planning.  Derive  action  (tactical)  plan  including:  mission,  critical 
success  factors,  improvement  actions,  process  goals  and  improvement 
targets  (measures),  responsibilities  for  actions,  initial  estimates  of  cost  and 
schedule,  deliverables,  communication,  and  verification  methods,  risks  to 
products  and  the  organization  if  actions  are  not  taken. 

Initiate  improvement  projects.  Initiate  projects  to  implement  action  plans; 
establish  the  process  action  teams  or  working  groups  who  will  work  to 
improve  the  priority  processes. 

Knowledge  and  skills:  action  planning,  goal  setting,  measurement,  team 
building,  risk  assessment,  understanding  of  process  improvement  standards 
and  models,  decision  making. 

6.1 .4  Improving  the  Process 

To  improve  the  processes  that  have  been  identified,  one  must  follow  a  process  level  improve¬ 
ment  approach.  (See  Section  5.6  and  also  Section  6.2.)  Process  level  improvement  activities 
are  carried  out  by  teams  [Scholtes  88]. 

Understand  the  process.  Describe/define  the  process,  identify  customer 
needs  and  concerns,  develop  a  standard  process. 

Eliminate  errors.  Identify  mistakes,  detect  defects,  identify  less  error-prone 
procedures,  restructure  the  work  environment. 

Remove  slack/streamline  the  process.  Examine  the  value  of  each  step, 
make  steps  more  efficient,  eliminate  steps,  eliminate  rework,  build  simpler 
products,  write  fewer  lines  of  code,  reduce  change-over  and  cycle  times, 
monitor  improvements. 

Reduce  variation.  Reduce  variation  in  measurement  systems,  bring  the 
measurement  process  under  statistical  control,  reduce  variation  in  the 
process,  eliminate  special  causes  of  variation,  bring  the  process  under 
statistical  control. 

Plan  for  continuous  improvement. 

PLAN  for  monitoring  of  changes  or  plan  a  change  or  a  test  aimed  at  im¬ 
provement. 

DO  the  monitoring  or  the  change  (preferably  on  a  small  scale);  plan  and 
execute  pilots. 


46 


CMU/SEI-95-TR-003 


CHECK  the  results  or  study  what  happened,  what  did  we  learn? 

ACT  to  make  continuous  improvements  (adopt  the  change  or  abandon  it 
and  go  through  the  cycle  again). 

Knowledge  and  skills:  problem  solving,  process  definition,  measurement, 
statistical  control,  defect  detection,  data  gathering,  data  reduction,  analysis, 
reporting. 

6.1 .5  Deploying  the  Improvement 

Processes  that  have  been  improved  in  a  controlled  environment  are  now  deployed  across  the 
organization. 

Confirm  improvements.  Confirm  that  planned  goals  and  targets  have  been 
reached;  re-evaluate  risks  associated  with  the  improved  process;  evaluate 
costs  and  benefits. 

Create  installation  and  rollout  plan.  Consider  training,  communication, 
timing,  reinforcement;  consider  rollout  alternatives:  piloting  in  small  areas, 
deploy  across  the  organization,  or  variations  in  between;  consider  costs, 
timing,  and  risks;  consider  environmental  changes:  human  and  cultural 
factors. 

Sustain  improvement  gains.  Monitor  institutionalization;  offer 
encouragement,  ensure  improved  processes  work  as  expected. 

Knowledge  and  skills:  risk  assessment,  cost/benefit  analysis,  training, 
communication,  organizational  issues,  transition  strategies,  culture  change. 

6.1.6  Leveraging 

The  improvement  cycle  repeats  to  incorporate  lessons  learned  and  continuously  improve  the 
process  improvement  process. 

Lessons  Learned.  Document  and  analyze  data  collected,  incorporate 
lessons  learned,  defect  prevention  for  next  cycle. 

Monitor  performance.  Review  the  continuing  process  improvement  effort  to 
ensure:  the  program  and  projects  remain  appropriate  to  organization’s  needs, 
further  projects  are  initiated  as  appropriate,  the  process  improvement 
process  itself  is  improved,  continuous  improvement  becomes  and  remains  a 
feature  of  the  organization’s  values,  attitudes,  and  behavior. 

Knowledge  and  skills:  data  analysis,  defect  prevention,  cost/benefit  analysis. 

6.2  Process  Management 

This  section  describes  generic  process  management  practices  used  to  manage  any  process. 
First  process  management  essentials  are  extracted  from  various  process  level  improvement 
approaches,  such  as  those  described  in  Section  5.6.  Then  we  describe  generic  process  man- 
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agement  practices  from  the  CMM  and  SPICE.  Lastly,  risk  management  practices  are  intro¬ 
duced  as  part  of  process  management. 

The  activities  described  here  may  be  carried  out  as  spin-off  projects  from  an  organizational 
process  improvement  program,  or  they  may  be  carried  out  by  a  project  team  seeking  to  im¬ 
prove  its  own  processes  following  a  middle-out  improvement  strategy. 

6.2.1  Basic  Process  Management  Activities 

Process  definition.  Deriving  a  standardized  framework  for  task 
implementation,  evaluation,  and  improvement;  documenting  standards  and 
procedures;  an  undefined  process  can  not  be  controlled;  an  uncontrolled 
process  can  not  be  improved  consistently. 

Process  execution.  Defining  the  methods  and  techniques  used  to  produce 
quality  products. 

Analysis.  Making  and  using  measurements  of  software  products  and 
processes;  establishing  baseline  process  performance. 

Process  control.  Establishing  mechanisms  to  ensure  performance  of 
defined  processes;  identifying  and  correcting  special  causes  of  poor  quality; 
keeping  process  performing  as  intended  within  control  limits  on  key  quality 
parameters. 

Process  improvement.  Identifying  and  rectifying  common  causes  of  poor 
quality  by  making  basic  changes  to  the  underlying  process. 

Knowledge  and  skills:  statistical  process  control,  measurement,  process 
definition,  teamwork,  problem  solving,  defect  detection  and  prevention, 
interaction  skills. 

6.2.2  Common  Features 

Common  features  of  process  management  pertain  to  generic  practices  or  activities  that  apply 
to  any  process.  Two  sets  of  common  features  are  provided:  those  attributes  that  offer  guid¬ 
ance  on  ways  to  ensure  that  a  process  is  effectively  managed  (CMM),  and  those  practices  that 
guide  process  managers  through  process  capability  levels  and  lead  to  the  continuous  im¬ 
provement  of  a  process  (SPICE). 

6.2.2.1  Common  Features  of  the  Capability  Maturity  Model  for  Software  (CMM) 

“The  common  features  are  attributes  that  indicate  whether  the  implementation 
and  institutionalization  of  a  key  process  area  is  effective,  repeatable,  and 
lasting." —CMM 


There  are  five  common  features  in  the  CMM,  and  the  key  process  areas  at  all  levels  are  orga¬ 
nized  by  common  features  [Paulk  93a]. 
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Commitment  to  perform.  Actions  the  organization  must  take  to  ensure  that 
the  process  is  established  and  will  endure,  such  as  establishing 
organizational  policies  and  senior  management  sponsorship. 

Ability  to  perform.  Preconditions  that  must  exist  in  the  project  or 
organization  to  implement  the  software  process  competently,  such  as 
securing  resources  and  funding,  organizational  structures,  and  training. 

Activities  performed.  Roles  and  procedures  necessary  to  implement  a  key 
process  area,  such  as  establishing  plans  and  procedures,  performing  the 
work,  tracking  it,  and  taking  corrective  actions  as  necessary. 

Measurement  and  analysis.  The  need  to  measure  the  process  and  analyze 
the  measurements  to  determine  the  status  and  effectiveness  of  the  activities 
performed. 

Verifying  implementation.  Steps  to  ensure  that  the  activities  are  performed 
in  compliance  with  the  process  that  has  been  established,  such  as  reviews 
and  audits  by  management  and  software  quality  assurance. 

6.2.2.2  Common  Features  of  the  Software  Process  Improvement  and  Capability  Deter¬ 
mination  Standard  (SPICE) 

“A  common  feature  is  a  set  of  practices  that  address  the  same  aspect  of 
process  implementation  or  institutionalization.” — SPICE 

There  are  eleven  Common  Features  (CFs)  in  the  SPICE  standard  and  they  are  ordered  by  ca¬ 
pability  level.  Each  is  elaborated  with  generic  practices  intended  to  enhance  the  capability  to 
perform  any  process.  The  generic  practices  are  listed  below  in  parentheses  after  each  com¬ 
mon  feature  [SPICE-BPG  94], 

Performed-lnformally  level  CFs.  Base  practices  are  performed  (perform  the 
process). 

Planned-and-Tracked  level  CFs.  Planning  performance  (allocate 
resources,  assign  responsibilities,  document  the  process,  provide  tools, 
ensure  training,  plan  the  process);  disciplined  performance  (use  plans, 
standards,  and  procedures;  do  configuration  management);  verifying 
performance  (verify  process  compliance,  audit  work  products);  tracking 
performance  (track  with  measurement,  take  corrective  action). 

Well-Defined  level  CFs.  Defining  a  standard  process  (standardize  the 
process,  tailor  the  standard  process);  performing  the  defined  process  (use  a 
well-defined  process,  perform  peer  reviews,  use  well-defined  data). 

Quantitatively-Controlled  level  CFs.  Establishing  measurable  quality  goals 
(establish  quality  goals);  objectively  managing  performance  (determine 
process  capability,  use  process  capability). 

Continuously-Improving  level  CFs.  Improving  organizational  capability 
(establish  process  effectiveness  goals,  continuously  improve  the  standard 
process);  improving  process  effectiveness  (perform  causal  analysis, 
eliminate  defect  causes,  continuously  improve  the  defined  process). 
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6.2.3  Risk  Management 

Risk  management  underlies  process  management  at  all  levels.  It  entails  knowing  how  to  de¬ 
termine  and  analyze  risks,  knowing  which  risks  are  most  important  to  look  for  and  why,  and 
knowing  how  to  mitigate  and  monitor  risks.  Several  risk  management  strategies  are  available 
[Carr  93],  [Boehm  89],  [Boehm  91],  [Charette  90], 

The  SEI  risk  management  paradigm  is  composed  of  different  software  development  risk  man¬ 
agement  activities.  The  objective  of  this  paradigm  is  to  provide  a  disciplined  and  systematic 
method  of  managing  software  development  risk  in  order  to  control  the  quality,  cost,  and  sched¬ 
ule  of  software  products  [Carr  93]. 

Identify.  Surfacing  risks;  raising  concerns  and  issues;  data  collection. 

Analyze.  Converting  risk  data  into  risk  decision-making  information; 
determining  the  “right”  risks  to  work  on. 

Plan.  Turning  risk  information  into  decisions  and  actions  through  planning; 
developing  actions,  prioritizing  risk  actions,  creating  an  integrated  risk 
management  plan. 

Track.  Monitoring  the  status  of  risks  and  actions  taken  to  ameliorate  risks; 
identifying  and  monitoring  risk  metrics  to  evaluate  status  of  risks  and  risk 
mitigation  plans. 

Control.  Correcting  for  deviations  from  planned  risk  actions. 

Communicate.  Pervasive  and  critical  to  this  paradigm;  communication  about 
risks  must  take  place  across  developers,  customers,  users;  to  and  between 
organizational  levels  and  entities. 

6.3  Organizational  Process  Management 

Here  we  provide  more  information  about  organizational  processes  of  the  CMM  for  software 
and  the  SPICE  Baseline  Practices  Guide.  Both  of  these  models  include  processes  for  organi¬ 
zational  process  improvement  and  management. 

6.3.1  Key  Process  Management  Processes  of  the  CMM 

The  key  process  areas  (KPAs)  at  levels  3, 4,  and  5  of  the  CMM  address  the  process  improve¬ 
ment  process  once  basic  project  management  processes  are  in  place.  These  KPAs,  along 
with  their  goals  and  examples  of  related  knowledge  and  skills,  are  described  below  [Paulk 
93a],  (Note  that  the  software  product  engineering  KPA  is  not  included  since  these  knowledge 
and  skill  areas  are  described  in  other  sources  such  as  in  Ford  [Ford  91].) 

Level  3  KPAs  focus  on  addressing  management  processes  across  all  projects. 

Organization  process  focus.  Establish  the  organizational  responsibility  for 
software  process  activities  that  improve  the  organization’s  overall  software 
process  capability. 
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Knowledge  and  skills:  process  control  techniques;  organizational  change 
management;  planning,  managing,  and  monitoring  the  software  process; 
technology  transition. 

Organization  process  definition.  Develop  and  maintain  a  usable  set  of 
software  process  assets  that  improve  process  performance  across  the 
projects  and  provide  a  basis  for  cumulative,  long-term  benefits  to  the 
organization. 

Knowledge  and  skills:  process  analysis  and  documentation  methods;  process 
modeling. 

Training  program.  Develop  the  skills  and  knowledge  of  individuals  so  they 
can  perform  their  roles  effectively  and  efficiently. 

Knowledge  and  skills:  training  in  instructional  techniques;  refresher  training  in 
the  subject  matter. 

Integrated  software  management.  Integrate  the  software  engineering  and 
management  activities  into  a  coherent,  defined  software  process  that  is 
tailored  from  the  organization’s  standard  software  process  and  related 
process  assets. 

Knowledge  and  skills:  methods  and  procedures  for  software  estimating, 
planning,  and  tracking  based  on  the  project’s  defined  software  process; 
methods  and  procedures  for  identifying,  managing,  and  communicating 
software  risks. 

Intergroup  coordination.  Establish  a  means  for  the  software  engineering 
group  to  participate  actively  with  the  other  engineering  groups  so  the  project 
is  better  able  to  satisfy  the  customer’s  needs  effectively  and  efficiently. 

Knowledge  and  skills:  building  teams;  managing  teams;  establishing, 
promoting,  and  facilitating  teamwork;  group  dynamics. 

Peer  reviews.  Remove  defects  from  the  software  work  products  early  and 
efficiently;  develop  a  better  understanding  of  the  software  work  products  and 
of  the  defects  that  can  be  prevented. 

Knowledge  and  skills:  types  of  peer  reviews;  objectives,  principles,  and 
methods  of  peer  reviews;  roles  of  reviewers;  estimating  the  effort  for  preparing 
and  participating  in  peer  reviews. 

Level  4  KPAs  focus  on  establishing  a  quantitative  understanding  of  both  the  software 
process  and  the  software  work  products  being  built. 

Quantitative  process  management.  Control  the  process  performance  of  the 
software  project  quantitatively. 
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Knowledge  and  skills:  modeling  and  analyzing  the  software  process;  selecting, 
collecting,  and  validating  process  measurement  data;  applying  basic 
quantitative  methods  and  analysis  techniques  (e.g.  estimation  models,  Pareto 
diagrams,  and  control  charts);  understanding  the  goals  and  value  of 
quantitative  process  management. 


Software  quality  management.  Develop  a  quantitative  understanding  of  the 
quality  of  the  project’s  software  products  and  achieve  specific  quality  goals. 

Knowledge  and  skills:  planning  quality  commitments  and  goals  for  the  product; 
measuring  product  and  process  quality;  controlling  product  quality  using  the 
defined  software  process;  understanding  the  goals  and  benefits  of 
quantitatively  managing  product  quality;  collecting  measurement  data; 
understanding  the  quality  measurements  for  the  software  process  and  product; 
planning  and  controlling  the  quality  of  the  software  product. 

Level  5  KPAs  focus  on  implementing  continuous  and  measurable  software  process  im¬ 
provement. 

Defect  prevention.  Identify  the  causes  of  defects  and  prevent  them  from 
occurring. 

Knowledge  and  skills:  defect  prevention  methods;  conduct  of  task  kick-off 
meetings;  conduct  of  causal  analysis  meetings;  statistical  methods  (e.g. 
cause/effect  diagrams  to  determine  root  causes  and  Pareto  analysis  to  set 
priorities  for  action  proposals). 


Technology  change  management.  Identify  beneficial  new  technologies 
(i.e.,  tools,  methods,  and  processes)  and  transfer  them  into  the  organization 
in  an  orderly  manner. 

Knowledge  and  skills:  technology  transfer  and  change  management;  principles 
of  statistical  quality  control. 

Process  change  management.  Continually  improve  the  software  process 
used  in  the  organization  with  the  intent  of  improving  software  quality, 
increasing  productivity,  and  decreasing  the  cycle  time  for  product 
development. 

Knowledge  and  skills:  managing  technological  and  organizational  change; 
team  building;  teamwork  skills  as  applied  to  continuous  process  improvement; 
principles  of  quality  and  process  improvement;  procedures  for  proposing 
process  improvements;  benchmarking  and  comparative  evaluation;  setting  and 
tracking  goals  for  process  improvement;  motivation  and  team  building  in  an 
environment  of  continuous  improvement. 

6.3.2  The  Organization  Process  Category  of  SPICE 

The  organization  process  category  of  the  SPICE  BPG  consists  of  processes  that  establish  the 
business  goals  of  the  organization  and  develop  process,  product,  and  resource  assets  to  help 
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the  organization  achieve  its  business  goals.  These  organizational  processes  build  organiza¬ 
tional  infrastructure,  take  the  best  of  what  is  available  in  any  one  part  of  the  organization,  and 
make  it  available  to  all  [SPICE-BPG  94]. 

The  processes,  and  their  base  practices,  are  as  follows: 

Engineer  the  business.  Establish  strategic  vision;  deploy  vision;  establish 
quality  culture;  build  integrated  teams;  provide  incentives;  define  career 
plans. 

Define  the  process.  Define  goals;  identify  current  activities,  roles  and 
responsibilities;  identify  inputs  and  outputs;  define  entry  and  exit  criteria; 
define  control  points;  identify  external  interfaces;  identify  internal  interfaces; 
define  quality  records;  define  process  measures;  document  the  standard 
process;  establish  policy;  establish  performance  expectations;  deploy  the 
process. 

Improve  the  process.  Identify  improvement  opportunities;  define  scope  of 
improvement  activities;  understand  the  process;  identify  improvements; 
prioritize  improvements;  define  measures  of  impact;  change  the  process; 
confirm  the  improvement;  deploy  improvement. 

Perform  training.  Identify  training  needs;  develop  or  acquire  training;  train 
personnel;  maintain  training  records. 

Enable  reuse.  Determine  organizational  reuse  strategy;  identify  reusable 
components;  develop  reusable  components;  establish  a  reuse  library;  certify 
reusable  components;  integrate  reuse  into  life  cycle;  propagate  change 
carefully. 

Provide  software  engineering  environment.  Identify  software  engineering 
environment  requirements;  provide  a  software  engineering  environment; 
provide  support  for  developers;  maintain  software  engineering  environment. 

Provide  work  facilities.  Provide  productive  workspace;  ensure  data 
integrity;  provide  data  backups;  provide  building  facilities;  provide  remote 
access  facility. 
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7  Culture  Change 


“Understand  the  lay  of  the  land  in  which  process  improvement  must  take  place. 
Organizations  are  like  jungles,  they  have  a  lot  of  interesting  and  sometimes 
dangerous  animals  hidden  in  the  weeds.” — customer  view 

It  is  widely  recognized  that  organizational  culture  must  change  to  enable  the  implementation 
and  institutionalization  of  process  improvement. 

Organizational  culture  includes  shared  values,  beliefs,  and  understandings.  It  indicates  which 
values  members  of  an  organization  should  adopt  in  order  to  behave  consistently  with  organi¬ 
zational  goals. 

We  begin  by  describing  the  general  nature  of  a  quality  culture  and  selected  new  organizational 
paradigms.  Then  we  describe  general  culture  change  concepts  and  some  strategies  that  can 
be  used  to  bring  about  change. 

7.1  Directions 

7.1.1  The  Nature  of  a  Quality  Culture 

What  is  the  nature  of  a  quality  culture?  It  is  typically  characterized  by  the  following  features: 

Shared  quality-based  values  and  goals.  Customer  focus,  obsession  with 
quality,  teamwork. 

Open  communication  paths.  Access  to  information,  stating  opinions  without 
fear,  listening  with  respect,  constructive  conflict,  negotiated  agreements  for 
work  and  relationships. 

Productivity  improvement.  Understanding  the  value  of  measurement, 
actively  working  to  improve  processes. 

Customer  value.  Continuously  increasing  value  to  external  and  internal 
customers. 

ISO  9004-4  describes  the  environment  considered  essential  for  quality  improvement 
[IS09004-4  93].  This  environment  includes  the  following: 

Management  responsibility  and  leadership.  To  communicate  purpose  and 
goals;  to  continuously  improve  their  own  work  processes;  to  foster  open 
communication,  teamwork  and  respect;  to  enable  and  empower  everyone  to 
improve. 
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Values,  attitudes,  and  behavior.  Satisfy  customer  needs;  involve  entire 
supply  chain  in  quality  improvement;  demonstrate  management  commitment, 
leadership,  and  involvement;  quality  improvement  is  part  of  everyone’s  job, 
either  by  teamwork  or  individual  activities;  address  problems  by  improving 
processes;  continuously  improve  all  processes;  establish  open 
communication  with  access  to  data  and  information;  promote  teamwork  and 
respect  for  the  individual;  make  decisions  based  on  analysis  of  data. 

Quality  improvement  goals.  Establish  quality  improvement  goals;  integrate 
them  with  overall  business  goals;  make  them  measurable,  understandable, 
challenging,  pertinent,  agreed  to  by  all,  regularly  reviewed,  reflective  of 
changing  customer  expectations. 

Communications  and  teamwork.  Open  communication;  teamwork;  trust; 
removal  of  organizational  and  personal  barriers  that  interfere  with 
effectiveness,  efficiency,  and  continuous  improvement  of  processes. 

Recognition.  Encourage  actions  consistent  with  values,  attitudes,  and 
behavior  necessary  for  quality  improvement;  emphasize  development  and 
growth  of  individuals;  emphasize  group  performance  and  group  recognition; 
encourage  frequent  and  informal  feedback;  make  reward  systems  consistent 
with  recognition;  do  not  promote  destructive  internal  competition. 

Education  and  training.  All  members  of  the  organization  should  be 
educated  and  trained  in  quality  principles,  practices,  and  methods  for  quality 
improvement;  training  programs  should  be  consistent  with  quality  principles 
and  practices;  effectiveness  of  education  and  training  should  be  regularly 
assessed. 

7.1.2  New  Organizational  Paradigms 

“The  organizational  culture  must  allow/encourage  change.” — customer  view 

Organizations  must  deal  with  complexity  and  change  to  achieve  competitive  advantage.  New 
organizational  paradigms  are  emerging  that  embrace  change  and  improvement  [Rensch  92]. 
They  are  based  on  shared  vision,  shared  values,  people  orientation,  employee  involvement, 
and  new  management  and  leadership  styles  -  essential  elements  in  a  process  improvement 
corporate  culture.  Two  examples  are  offered  here  [Senge  90],  [Peters  87].  Others  are  refer¬ 
enced  in  the  Appendix. 

7.1 .2.1  Learning  to  be  a  Learning  Organization 

“The  organizations  that  will  truly  excel  in  the  future  will  be  the  organizations  that 
discover  how  to  tap  people’s  commitment  and  capacity  to  learn  at  a II  levels  in 
an  organization.  ”  — Peter  Senge 


The  core  disciplines.  Personal  mastery,  mental  models,  shared  vision,  team 
learning. 

The  fifth  discipline.  Systems  thinking. 
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Learning.  Examining  successes  and  failures;  experimentation,  observation, 
analysis;  responding  to  a  wide  variety  of  different  alternatives;  making  inquiry 
and  commitment  to  truth  the  norm;  challenging  the  status  quo;  motivating 
people  to  learn,  and  thus  improve  [Senge  90], 

7.1 .2.2  Thriving  on  Chaos 

“If  it  ain’t  broke,  you  just  haven’t  looked  hard  enough.  Fix  it  anyway. ”  — Tom 
Peters 

Creating  total  customer  responsiveness,  pursuing  fast-paced  innovation, 
achieving  flexibility  by  empowering  people,  and  learning  to  love  change 
creates  a  new  view  of  leadership  at  all  levels;  building  systems  for  a  world 
turned  upside  down  [Peters  87]. 

7.1.3  Leadership  and  Management 

“Institute  leadership.” — W.E.  Deming 

“...unless  the  organization’s  executives  are  ready  and  willing  to  support  the 
change  efforts  (through  their  altered  management  practices)  it  might  be  a 
disappointing  exercise  for  those  who  so  want  to  implement  change...”  — a 
change  agent 

“We  will  assure  strategic  clarity  and  consistency;  we  will  provide  visible 
supportive  management  practices,  commitments,  and  leadership;  we  will  set 
quality  objectives  and  measurement  standards;  we  will  establish  an 
environment  so  each  person  can  be  responsible  for  quality.” — XEROX 
[XEROX  86] 

New  and  changing  roles  are  being  defined  as  organizations  shift  towards  a  quality  culture.  An 
essential  part  of  organizational  change  consists  of  augmenting  management  skills  to  meet 
changing  needs.  Management  roles  will  change;  leadership  will  emerge  at  all  levels  of  the  or¬ 
ganization. 

Predominant  themes  are  summarized  below. 

Management  responsibility  and  leadership.  To  communicate  purpose  and 
goals;  to  continuously  improve  their  own  work  processes;  to  foster  open 
communication,  teamwork  and  respect;  to  enable  and  empower  everyone  to 
improve. 

Leadership  responsibilities.  To  promote  thinking  and  acting  at  all  levels  of 
the  corporation;  to  aspire  to  serve;  to  learn  who  lies  outside  the  system  thus 
needing  help  or  deserving  recognition;  to  improve  the  system;  to  accomplish 
consistency  of  performance  within  the  system. 

Leadership  skills.  Ability  to  build  shared  vision;  to  surface  and  challenge 
prevailing  mental  models;  to  foster  systematic  patterns  of  thinking;  to  enable 
people  to  expand  their  capabilities  and  shape  their  futures. 
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Management  style.  Open  style  with  clear  and  consistent  objectives  that 
encourage  group-derived  continuous  improvement. 

Role  of  manager.  Communicate,  consult,  delegate,  coach,  mentor,  remove 
barriers,  and  establish  trust. 

Rewards  and  recognition.  Individual  and  group  recognition  and  rewards; 
negotiated  criteria;  sustaining  the  improvement  effort. 

Emerging  management  competencies.  Reading  the  environment;  active 
management;  leadership  and  vision;  empowering  human  resources; 
promoting  creativity,  learning,  and  innovation;  skills  in  remote  management; 
using  information  technologies;  managing  complexity  and  ambiguity; 
broadening  competencies  and  reframing  contexts. 

Teams  as  the  basic  organizational  building  block.  Train  them,  recruit  for 
them,  reward  them,  foster  cooperation,  change  the  role  of  middle 
management. 

Required  middle  management  changes.  From  scheduler  to  coach;  from 
enforcer  to  facilitator;  from  vertical  to  horizontal  focus;  from  transmitting  top 
management  needs  down  to  selling  teams’  ideas  up;  from  providing  ideas 
down  to  helping  teams  develop  their  own  ideas. 

7.1 .4  The  People  Management  Capability  Maturity  Model 

The  People  Management  Capability  Maturity  Model  v.0.2  (draft  for  public  review)  is  a  maturity 
framework  that  describes  the  key  elements  of  managing  and  developing  the  talent  of  an  orga¬ 
nization.  This  framework  includes  key  process  areas  pertaining  to  organizational  culture,  val¬ 
ues,  and  teamwork  [Curtis  94].  These  (selected)  key  process  areas  are  as  follows: 

People  management  values  development.  Create  a  culture  that  values  the 
talent  of  the  organization  and  supports  the  implementation  of  advanced 
people  management  practices. 

Compensation  and  reward.  Motivate  each  staff  member  to  maximize  their 
contribution  and  value  to  the  organization. 

Participatory  culture.  Incorporate  the  knowledge  of  staff  members  into 
decision-making  processes. 

Team  building.  Capitalize  on  opportunities  to  create  teams  that  maximize 
the  integration  of  diverse  knowledge  and  skills  to  best  perform  a  business 
function. 
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7.2  Change  Concepts 


“...[our  major  problem  is] ...  resistance  to  change,  changes  needed  in 
management  and  practitioner  paradigms,  typical  dysfunctional 
interrelationships  and  communications  modes.’’ — a  change  agent 

7.2.1  Corporate  Culture 

For  each  organization,  the  nature  of  its  desired  culture  (“Who  are  we?”)  must  be  established 
before  change  can  take  place.  Leaders  must  recognize  the  importance  of  corporate  introspec¬ 
tion. 


Creating  and  projecting  a  vision.  Who  you  are  and  what  you  value. 

Guiding  beliefs.  The  target  of  how  things  ought  to  be:  defining  corporate 
roots,  principles,  philosophical  foundations;  determining  why  the  organization 
exists. 

Corporate  strategy.  Establishing  what  an  organization  wants  to  accomplish. 

Daily  beliefs.  How  things  are,  actual  behaviors,  rules  and  survival  kits. 

Linking.  Guiding  beliefs,  strategy,  and  daily  beliefs. 

7.2.2  Technology  Transfer 

Technology  transfer  is  the  utilization  of  knowledge  [Glaser  83].  This  knowledge  may  pertain  to 
a  vision  of  the  corporate  culture,  a  process  improvement  method,  or  a  specific  software  engi¬ 
neering  tool.  The  idea  is  to  put  that  knowledge  into  practice. 

There  are  factors  that  influence  the  likelihood  of  technology  adoption  or  adaption  (and  behav¬ 
ioral  models  of  change)  and  they  are  important  concepts  for  those  involved  in  culture  change. 

Variables  influencing  acceptance  of  change.  Relative  advantage, 
compatibility  with  values,  comprehensibility,  practicability,  demonstrability 
and  trialability,  championship  (advocacy  by  influential  persons), 
appropriateness  of  timing  and  circumstance. 

Personal  and  social  influences.  Psychosocial  considerations,  economic 
and  social  status,  professional  qualities,  personality  and  role  of  the  leader, 
psychological  attributes,  resistance  to  change. 

Organizational  factors.  Organizational  climate  and  quality  of  worklife, 
organizational  goals,  organizational  structure,  organizational  communication 
and  decision  making,  organizational  dynamics,  organizational  behavior,  the 
power  and  pitfalls  of  the  “hidden”  organization. 

Political,  economic  and  sociocultural  processes. 

Organizational  paradigms.  Closed,  random,  open,  synchronous 
[Constantine]. 
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General  strategies  for  achieving  change.  Coercive,  normative,  utilitarian, 
empirical-rational,  normative-reeducative,  power-coercive,  persuasive, 
individual-change,  data-based,  organizational  development,  direct-action, 
manipulative,  facilitation. 

Key  aspects  of  technology  transfer.  Context  analysis  (social  and  technical 
aspects  of  the  environment,  frames  of  reference);  mapping  (determining 
whether  a  technology  is  likely  to  succeed  in  an  organization);  boundary 
spanners  (people  who  perform  the  mapping  process). 

7.2.3  Organizational  Change 

Stages  of  commitment  to  organizational  change.  Contact,  awareness, 
understanding,  positive  perception,  installation,  adoption,  institutionalization, 
internalization. 

Characteristics  of  the  change  process.  Unfreezing  (discovering  and 
accepting  the  need  for  change);  transition  (moving  from  current  state  to  a 
more  desirable  state);  refreezing  (changes  become  routine  organizational 
behavior,  refocus  on  the  product  rather  than  the  process). 

Transition  management.  Unfreezing  the  present  state,  refreezing  the 
desired  state;  drivers  of  change:  opportunity,  need,  discomfort,  pain; 
transition  phases:  contact,  awareness,  understanding,  installation,  adoption, 
institutionalization;  communication  and  reinforcement  tactics. 

Resistance.  Resistance  patterns:  uninformed  certainty,  informed  doubt, 
realistic  concern,  informed  certainty,  stunned  paralysis,  denial,  anger, 
bargaining,  fear,  depression,  exploration,  acceptance;  assessing  resistance; 
managing  resistance;  dealing  with  resistance. 

Roles  and  responsibilities.  Sponsors,  targets/contributors,  change  agents, 
champions;  visionary  leadership. 

Communication.  Frames  of  reference;  the  Myers-Briggs  Type  Indicator; 
Wilson  Learning. 

Culture.  Behaviors,  values,  unwritten  rules;  culture  assessment:  barriers  and 
leverage  points. 


7.3  Change  Strategies 

“Our  culture  rewards  the  fire  fighter.  How  can  others  want  to  improve,  when  fire 
fighting  is  rewarded?”  — customer  view 


“When  customers  demand  process  improvement,  organizations  will  respond.” 
— customer  view 


There  are  several  approaches  to  bringing  about  culture  change.  An  organization  must  choose 
the  most  suitable  approach.  There  are  many  approaches  to  understand  and  evaluate.  A  syn¬ 
thesis  of  various  approaches  may  be  most  suitable  depending  on  organizational  needs.  We 
selected  a  few  for  inclusion  here.  Others  are  referenced  in  the  Appendix. 
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7.3.1  Adapting  Process  Improvement  Approaches 

Culture  change  can  be  viewed  as  a  process  improvement  endeavor  that  uses  the  same  steps 
and  activities  described  in  Section  6.  The  main  differences  are  that  the  mechanisms  used  to 
improve  the  culture  deal  with  behavioral  change  rather  than  process  change,  i.e.,  the  way  the 
people  carry  out  worklife  processes  is  changed  rather  than  the  worklife  process  itself. 

This  generic  approach  might  entail  the  following  steps:  initiating  the  culture  change  effort  (in¬ 
cluding  establishing  vision  and  goals),  baselining  the  current  culture  and  determining  culture 
gaps,  establishing  priorities  and  action  plans  (including  measures)  for  changing  selected  parts 
of  the  culture,  implementing  the  plan  within  a  pilot  area  of  the  organization,  reviewing/revising 
based  on  pilot  results,  deploying  the  change  throughout  the  organization,  assessing  results  of 
that  culture  change  effort,  and  recycling  through  next  culture  change  areas. 

Actions  may  result  in  training  on  culture  issues,  enhancing  managerial  skills,  or  establishing 
new  rewards  and  recognition  systems. 

7.3.2  The  Managing  Technological  Change  System 

The  Managing  Technological  Change  system  is  a  structured  approach  to  managing  the  hu¬ 
man  elements  that  are  critical  to  achieving  strategic  business  objectives.  The  eight  compo¬ 
nents  of  the  approach  are  designed  to:  collect  information  about  the  target  organization  with 
respect  to  an  implementation  effort,  assemble  the  data,  and  build  an  implementation  plan  that 
will  increase  the  likelihood  of  success  [Myers]. 

Eight  components  of  Managing  Technological  Change.  Project  overview, 
implementation  history  assessment,  sponsorship  assessment,  target 
resistance  assessment,  culture  assessment,  change  agent  assessment, 
assessment  review,  implementation  plan. 

Implementation  plan  components.  Assessment  analysis,  preliminary 
planning,  diagnostics,  key  roles,  sponsorship,  change  agent  development, 
reinforcement,  communication,  target  resistance,  cultural  resistance, 
monitoring  and  tracking. 

Manage  the  human  elements  of  change.  Identify  change  barriers;  assess 
skills  and  motivation  of  key  stakeholders  authorizing  and  reinforcing  the 
change;  identify  criteria  for  selecting  and  evaluating  key  players  responsible 
for  implementing  change;  identify  potential  for  and  sources  of  resistance; 
develop  and  apply  strategies  and  tactics  to  drive  change;  develop  effort 
estimates  for  the  change. 

7.3.3  Streams  of  Activity  Model  (Joiner  Associates) 

This  approach  identifies  five  streams  of  activities  that  are  parallel,  unending,  and  address  all 
underlying  elements  that  must  be  present  for  a  successful  improvement  effort.  These  activities 
are  as  follows  [Joiner  89]: 

Support  culture,  climate,  and  environment. 
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Improve  performance  through  quality  management. 

Review  through  quality  management. 

Develop  internal  resources. 

Build  education  and  training  community. 

7.3.4  Logistics  Management  Institute — Continuous  Improvement 
Process 

This  model  focuses  on  organizational  and  behavioral  change  needed  to  instill  and  sustain  a 
culture  of  continuous  improvement.  The  objective  is  to  establish  a  perpetual  and  total  commit¬ 
ment  to  quality,  and  to  involve  everyone.  Adaptations  of  this  model  exist  at  the  process  and 
individual  level  (See  Section  5.)  [Mansir  89]. 

Envisioning.  Develop  vision,  build  awareness,  evolve  mission  statement, 
establish  steering  committee. 

Enabling.  Develop  top  management  commitment,  shape  environment, 
provide  resources,  empower  the  organization. 

Focusing.  Establish  goals,  deploy  goals  and  policy,  involve  customers  and 
suppliers. 

Improving.  Define  and  standardize  processes,  assess  process  performance, 
improve  processes,  measure  progress. 

Learning.  Identify  needs,  obtain  materials,  develop  learning  methods,  train 
and  educate  everyone  just  in  time. 

Team  building.  Form  teams  in  accordance  with  goals,  integrate  natural  work 
groups,  form  cross-functional  teams,  pursue  process  improvement  activities. 

7.3.5  Establishing  a  Personal  Improvement  Culture 

Some  approaches  to  individual  process  improvement  were  described  in  Section  5.7.  We  in¬ 
clude  one  more  example  of  a  bottom-up  approach  to  process  improvement  that  starts  with  the 
individual,  and  works  up  through  groups  and  then  to  top  management. 

This  approach  advocates  using  quality  tools  to  improve  your  own  processes,  extending  this 
approach  to  groups,  and  then  approaching  management  [Forsha  92], 

Personal  change  is  first.  Using  quality  tools  for  personal  change. 

Group  change  is  next.  Developing  relationships:  communicating  with 
personal  integrity,  self-respect,  respect  for  others,  understanding  needs; 
interpersonal  communication. 
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Changing  management  attitudes  is  next.  Recognizing  behavior  styles; 
communicating;  selecting  early  doable  projects;  creating  a  positive  track 
record;  creating  awareness  of  the  need  for  change;  prioritize,  provide  vision 
of  expected  results;  establish  and  monitor  indicators;  redefinition,  coalition, 
and  merging  of  views;  salesmanship;  negotiation;  working  with  subordinates, 
peers,  and  management  for  consensus;  overcoming  barriers. 

Techniques  and  skills  to  use. 

Quality  improvement  process.  Problem  identification,  problem  analy¬ 
sis,  planning,  data  collection,  data  interpretation,  action,  appraisal. 

Quality  tools.  Concept  development  tools.  These  tools  are  used  to  start 
the  change  process,  to  generate  ideas,  to  narrow  them  down,  to  derive  a 
statement  of  direction:  brainstorming,  checklist,  five  whys,  rating  systems, 
prioritizing  and  the  decision  matrix,  visualization,  flowchart,  the  objective 
statement  (who,  what,  when,  where,  how,  plus  success  measures). 

Behavioral  styles.  Thinker,  director,  socializer,  relator;  understanding 
and  dealing  with  different  types  of  social  behavior. 
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8  Process  Improvement  Tools  and  Techniques 


Tools  and  techniques  for  process  improvement  are  emerging  as  the  topic  itself  is  evolving. 
Many  of  the  tools  of  quality  are  applicable  to  software  process  improvement.  Research  in  pro¬ 
cess  centered  software  engineering  promises  to  provide  new  tools  and  methods.  In  this  sec¬ 
tion  we  describe  tools  and  techniques  that  can  be  used  in  carrying  out  process  improvement 
activities. 

8.1  Customer  Value 

A  process  improvement  culture  focuses  on  the  customer. 

8.1 .1  Customer  Value  Determination 

Customer  Value  Determination  is  used  to  find  out  what  your  customers  need  and  want;  to  find 
out  what  your  competitive  advantages  are;  to  obtain  your  customers’  views  regarding  where 
you  need  improvement  [Stahl  91]. 

Techniques  for  projecting,  challenging,  discovering,  and  confirming  net 
customer  value  for  your  business. 

8.1.2  Quality  Function  Deployment 

Quality  Function  Deployment  (QFD)  is  used  to  build  quality  products  while  reducing  cycle  time 
[Zultner  92],  [Thompson  89]. 

How  to  deploy  customer  value  information  into  products  so  they  meet/exceed 
customer  net  value  targets:  the  House  of  Quality. 

8.1 .3  The  Wheel  of  Improvement 

The  Total  Quality  Control  (TQC)  wheel  portrays  core  skills  and  methods  needed  for  improve¬ 
ment,  and  explains  their  use  in  relation  to  the  achievement  of  the  organization’s  improvement 
goals  [King  89]. 

Center  of  wheel.  Customer  Driven  Master  Plan:  a  5-10  year  strategic  plan 
surrounded  by  three  systems  plus  their  supporting  techniques  and  methods. 

Dally  control  system.  Supported  by  statistical  methods,  work  groups  TQC 
Circles,  standardization. 

Hoshin  planning  system.  Supported  by  continuous  improvement,  vertical 
teams,  and  the  seven  “M”  tools. 

Cross  functional  management  system.  (Quality,  Cost,  Delivery, 
Profit/Product).  Supported  by  quality  assurance/quality  function  deployment; 
horizontal  customer/supplier  teams;  information  system;  audit  tools. 
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8.2  Problem  Solving 

Problem  solving  involves  problem  definition  (distinguishing  between  causes  and  symptoms) 
and  decision  making  (analyzing  the  problem  to  identify  solutions  and  choosing  among  them). 
Several  tools  and  techniques  are  available  for  solving  process  problems  [Brassard  89],  [Imai 
86],  [Kan  92],  [Scholtes  88], 

8.2.1  Data  Gathering 

Problem  solving  often  requires  data  collection  as  a  first  step.  Typical  data  gathering  tools  are 
the  following: 

Interviews.  Structured  or  unstructured;  telephone  or  face-to-face. 

Brainstorming.  Structured  or  unstructured. 

Nominal  Group  Technique 

Focus  groups.  Structured  group  interviews;  can  use  group  data  gathering 
tools  such  as  brainstorming,  nominal  group  technique. 

Surveys.  Formal  or  informal. 

Observation. 

8.2.2  Analytical  Problem  Solving  (The  Seven  Tools) 

These  tools  can  help  teams  diagnose  and  solve  quality  improvement  problems.  Also  known 
as  the  seven  statistical  tools,  the  seven  quality  control  tools,  and  the  Q  seven,  they  are  used 
when  data  are  available  and  the  task  is  to  analyze  the  data  to  solve  a  particular  problem  [Imai 
86].  The  seven  statistical  tools  used  for  analytical  problem-solving  are: 

Pareto  diagrams.  These  diagrams  illustrate  the  frequency  or  effect  of 
problems.  The  problem  data  are  charted  according  to  frequency  or  effect  in 
decreasing  order  using  a  bar-graph  format.  These  diagrams  help  to 
determine  the  order  in  which  to  solve  problems  by  drawing  attention  to  the 
vital  few  truly  important  problems. 

Cause-and-effect  diagrams.  Also  called  fishbone  and  Ishikawa  diagrams 
due  to  their  appearance  and  originator,  respectively,  these  are  used  to 
analyze  the  characteristics  of  a  process  or  situation  and  the  factors  that 
contribute  to  them.  They  represent  the  relationship  between  some  effect  and 
possible  causes  influencing  that  problem  or  condition. 

Histogram.  A  histogram  graphically  represents  the  measurement  data  on  a 
bar  chart.  It  reveals  the  amount  of  variation  within  process  data  and  can  be 
used  to  study  the  distribution  of  the  problem  data. 
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Control  chart.  A  control  chart  is  used  to  discover  how  much  variability  in  a 
process  is  inherent  (due  to  common  causes  or  random  variation)  and  how 
much  is  due  to  special  causes  (unpredictable  individual  actions).  A  control 
chart  is  the  same  as  a  run  chart  in  that  it  displays  observations  over  periods 
of  time,  but  the  control  chart  has  statistically  determined  upper  and  lower 
control  limits. 

Scatter  Diagram.  A  scatter  diagram  is  used  to  display  what  happens  to  one 
variable  when  another  variable  changes.  It  is  used  to  test  the  theory  that  the 
two  variables  are  related  and  to  study  possible  relationships  between 
variables.  A  scatter  diagram  has  a  horizontal  axis  to  represent  the 
measurement  values  of  one  variable,  and  a  vertical  axis  to  represent  the 
measurement  of  the  second  variable. 

Graphs.  There  are  many  kinds  of  graphs  or  charts  that  can  be  employed, 
depending  on  the  shape  desired  and  the  purpose  of  analysis.  Bar  graphs 
compare  values  via  parallel  bars;  line  graphs  illustrate  variations  over  time; 
circle  graphs  or  pie  charts  indicate  percentage  breakdown  of  values  (slices  of 
the  pie). 

Checksheets.  These  are  designed  to  record  and  tabulate  data  by  using 
simple  checkmarks  to  indicate  situations  or  events.  Checksheets  answer  the 
question  “How  often  are  certain  events  happening?” 

8.2.3  Design  Problem  Solving  Tools  (The  New  Seven) 

Design  problem  solving  is  used  when  data  are  not  available  or  data  is  subjective  and  there  is 
a  need  for  collaboration  among  people  [Imai  86].  They  may  be  used  to  plan  for  the  quality  and 
design  of  new  processes  or  to  reengineer  existing  ones. 

These  seven  quality  control  tools  are  sometimes  referred  to  as  the  NEW  Seven  or  the  7  M 
tools  for  group  design,  planning,  and  management. 

Relations  diagram  (or  relationship  chart).  This  diagram  shows  the 
interrelationships  in  a  complex  situation  (one  that  involves  many  interrelated 
factors)  and  clarifies  the  cause-and-effect  relationships  among  factors. 

Affinity  diagram.  This  method  is  applied  to  a  brainstorm  result  or  to  group 
work  in  which  the  ideas  are  grouped  by  subject  matter,  and  it  organizes  and 
realigns  the  data. 

Tree  diagram.  This  is  an  extension  of  the  value  engineering  concept  of 
functional  analysis  and  it  shows  the  interrelationships  among  goals  and 
measures. 

Matrix  diagram.  This  format  is  used  to  show  the  relationship  between  two 
factors. 

Matrix  data-analysis  diagram.  This  diagram  is  used  when  the  matrix  chart 
does  not  provide  sufficiently  detailed  information. 
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Process  decision  program  chart  (PDPC).  This  is  used  to  decide  the  critical 
things  to  do  first  to  improve  a  process.  Because  implementation  programs  to 
achieve  specific  goals  do  not  always  follow  their  plans,  and  because 
unexpected  developments  are  likely  to  have  serious  consequences,  PDPC 
has  been  developed  not  only  to  arrive  at  the  optimum  conclusion  but  also  to 
avoid  surprises. 

Arrow  diagram.  This  uses  a  network  representation  to  show  the  steps 
necessary  to  implement  a  plan. 

8.2.4  Other  Problem  Solving  Tools 

In  addition  to  the  14  tools  listed  above,  there  are  a  number  of  other  problem  solving  and  deci¬ 
sion  making  tools  [Brassard  89]. 

Flowchart.  A  flowchart  is  a  pictorial  representation  showing  all  of  the  steps  of 
a  process.  Flowcharts  are  widely  used  for  problem  identification  in  a  process 
called  IMAGINEERING.  The  people  with  important  knowledge  about  the 
process  meet  to:  draw  a  flowchart  of  what  steps  a  process  actually  follows, 
draw  a  flowchart  of  what  steps  the  process  should  follow,  then  compare  the 
two  charts. 

Process  capability.  Process  capability  is  used  to  determine  whether  the 
process,  given  its  natural  variation,  is  capable  of  meeting  established 
(customer)  specifications. 

Force  Field  Analysis.  Force  Field  Analysis  is  used  to  analyze  two  opposite 
condition  or  situations. 

Group  problem  solving  to  reach  consensus.  (See  Section  9.) 

8.3  Statistical  Techniques 

Statistical  methods  have  broad  applications  in  determining  and  monitoring  process  improve¬ 
ment  activities.  Statistical  data  analysis  is  used  to  transform  data  into  useful  information  for 
decision  making.  Commonly  used  statistical  techniques  used  in  process  improvement  are  as 
follows: 


Design  of  experiments.  Design  of  experiments  is  an  analytical  technique 
that  enables  testing  of  many  factors  in  each  experiment  and  thus  helps 
identify  which  variables  have  the  most  influence  on  the  overall  outcome.  It 
refers  to  the  structure  of  an  experiment,  with  particular  reference  to:  (a)  the 
set  of  treatments  included  in  the  study,  (b)  the  set  of  experiment  units 
included  in  the  study,  (c)  the  rules  and  procedures  by  which  treatments  are 
assigned  to  the  experiment  unit,  and  (d)  the  measures  that  are  made  on  the 
experimental  units  after  the  treatments  have  been  made. 
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Sampling.  Sampling  involves  identifying  the  population  of  experimental  units 
and  developing  a  scheme  that  selects  a  subset  of  the  population  in  such  a 
way  that  each  experiment  has  an  actual  chance  of  being  in  the  subset 
chosen.  The  subset  is  referred  to  as  a  simple  random  sample  (in  this  case). 
A  stratified  random  sample  is  produced  by  applying  a  population  sampling 
scheme  to  each  stratum. 

Statistical  data  reduction  tools.  Mean,  median,  range,  standard  deviation, 
correlation,  regression,  and  chi-square. 

Graphical  data  reduction  techniques.  Two-  or  three-dimensional  plots,  bar 
charts,  pi  charts,  etc. 

Statistical  process  control.  The  premise  of  statistical  process  control  is  that 
data  variations  fall  into  two  categories:  those  that  are  endemic  to  the  system 
and  the  processes  in  place  ( common  causes  of  variation),  and  those  that  are 
due  to  specific  circumstance  such  as  lack  of  understanding  of  operators  or 
defective  equipment  (special  causes  of  variation).  The  two  types  of  data  are 
separated  by  plotting  all  data  on  a  run  chart  and  calculating  control  limits. 
Data  that  are  between  the  upper  and  lower  limits  represent  variations  due  to 
process  and  data  above  the  upper  limit  and  below  the  lower  limit  represent 
special  causes  of  variation. 

Robust  statistics. 

Box  plot. 


8.4  Cost/Benefit  Analysis 

Measuring  the  benefits  of  process  improvement  is  itself  a  process  [Rozum  93].  The  software 
process  improvement  benefit  index  recommended  by  SEI  is  the  ratio  of  dollars  saved  [(cos- 
t(old)  -  cost(new)]  divided  by  the  old  cost. 

Software  process  improvement  cost.  There  are  two  types  of  cost 
associated  with  a  process  improvement  program:  nonrecurring  cost,  and 
recurring  cost.  Nonrecurring  cost  includes  consultants,  training,  standards 
change,  planning,  pilot  testing,  and  implementation.  Recurring  cost  includes 
overhead,  error  prevention,  process  monitoring,  error-detection,  etc. 

Measuring  savings.  The  amount  of  money  saved  can  be  calculated  by 
quantifying  the  dollar  value  of  items  such  as:  increased  productivity,  early 
error  detection  and  correction,  overall  reduction  of  errors,  improved  trends  in 
maintenance  and  warranty  work,  elimination  of  processes  or  process  steps. 

Processes  can  be  analyzed  quantitatively  by  means  of  various  costing  methods  such  as  ac¬ 
tivity-based  costing  (ABC).  Under  ABC,  costs  can  be  assigned  to  process  activities  to  facilitate 
decision  making  for  investment  justification  and  process  management  [Elzinga  95],  [Jeans 
89], 
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8.5  Risk  Assessment  Techniques 

Risk  assessment  consists  of  risk  identification  (determining  which  risk  events  are  likely  to  af¬ 
fect  the  process  improvement  project),  risk  quantification  (evaluating  the  range  of  possible  out¬ 
comes  and  their  likelihood  of  occurrence),  and  risk  mitigation  (defining  steps  for  mitigation). 

Risk  identification  tools.  Checklist,  historical  results,  interviewing. 

Risk  quantification  tools.  Expected  monetary  value,  statistical  sums, 
schedule  simulation,  decision  trees. 

Risk  mitigation  tools.  Contracting,  contingency  planning,  alternative 
strategies,  insurance. 

8.6  Defect  Detection  and  Prevention 

Defect  prevention  is  a  systematic  way  of  reducing  the  number  of  defects  in  a  work  product. 
This  goal  is  achieved  by  deploying  a  process  that  does  not  introduce  defects  in  the  first  place. 

First,  defects  must  be  detected.  Peer  reviews  can  be  used  to  identify  defects  and  to  help  un¬ 
derstand  the  types  of  defects  that  can  be  prevented.  Two  commonly  used  peer  review  tech¬ 
niques  are  inspections  and  walkthroughs. 

Inspections.  Inspections  follow  a  formal  process  with  defined  roles, 
activities,  and  deliverables.  Statistics  are  recorded  on  defects  detected  and 
detection  rates.  Defects  are  later  corrected. 

Walkthroughs.  Walkthroughs  are  a  less  formal  type  of  inspection  intended 
to  provide  constructive  feedback  to  improve  the  product  being  reviewed. 

After  defect  data  are  available,  problem  solving  methods  such  as  cause-and-effect  diagrams 
and  Pareto  diagrams  can  be  used  to  determine  root  causes  of  the  defects  and  to  set  priorities 
for  methods  to  prevent  them  from  occurring. 

8.7  Benchmarking 

Benchmarking  is  a  technique  used  to  improve  an  organization  by  comparing  what  that  orga¬ 
nization  does  to  what  others  do.  It  involves  measuring  products,  services,  and/or  practices 
against  tough  competitors  or  recognized  leaders,  and  developing  plans  to  adopt  the  best  prac¬ 
tices  found  [Shattuck  93]. 

Benchmarking  process.  Planning  (identify  benchmarking  subject,  identify 
benchmarking  partners,  determine  data  collection  method,  collect  data); 
Analysis  (determine  current  competitive  gap,  project  future  performance); 
Integration  (communicate  findings  and  gain  acceptance,  establish  functional 
goals);  Action(develop  action  plans,  implement  plans  and  monitor  progress); 
Maturity  (recalibrate  benchmark). 

Types  of  benchmarking.  Internal,  competitive,  functional,  strategic/ 
performance,  process/functional,  product. 
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8.8  Process  Definition 

Processes  are  defined  so  people  in  organizations  understand  their  roles,  responsibilities,  de¬ 
pendencies,  and  how  to  do  business.  A  process  definition  document  is  wrapped  around  a  pro¬ 
cess  model  and  its  purpose  is  to  guide  the  developers  in  performing  their  tasks.  A  process 
definition  document  is  analogous  to  a  play  book  employed  by  a  professional  team.  It  describes 
what,  who,  when  and  why  surrounding  a  task  that  needs  to  be  done. 

Descriptive  process  model.  A  detailed  and  formalized  representation  of 
software  life-cycle  activities  that  is  characterized  by  a  set  of  notations  to 
represent  objects,  transforms  and  events. 

Process  representation  notations.  There  are  a  number  of  notations  for 
process  representations.  They  are  either  text-based  notations  or  a 
combination  of  graphics  and  text.  A  process  is  viewed  from  a  number  of 
perspectives:  functional  (indicates  process  steps);  organizational  (shows 
who/what  performs  each  function);  behavioral  (identifies  what  the  process 
states  are);  informational  (depicts  the  information  structure  and  the 
information  relationships).  Currently  there  is  not  one  notation  that  is  equally 
strong  in  representing  a  process  from  all  perspectives.  Some  commonly  used 
notations  are: 

State  Transition  Diagrams  (STDs).  STDs  are  used  for  finite  state 
machines.  Any  process  that  can  be  described  in  terms  of  a  finite 
automaton  can  be  represented  using  an  STD.  Finite  state  machines 
provide  a  possible  representation  for  modeling  sequences  of  events 
within  some  defined  domain. 

Entry-Task-Validation-Exit  (ETVX).  ETVX  is  a  quasi-diagrammatic 
representation  identifying  entry  criteria,  tasks  to  be  performed, 
validation  requirements,  and  exit  criteria. 

Structured  Analysis  and  Design  Technique  (SADT).  The  SADT 
approach  involves  identifying  activities,  and  then:  identifying  the  input 
and  output  of  these  activities,  identifying  factors  that  constrain  the 
activities,  and  identifying  resources  and  materials  that  support  the 
activities. 

Statecharts.  Statecharts  allow  a  finite  automaton  to  be  decomposed 
into  representations  that  model  two  or  more  interacting  or 
communicating  subsystems. 

Petri  nets.  Petri  nets  have  been  used  to  model  manufacturing 
processes,  chemical  processes,  and  hard  real-time  embedded 
processes.  An  important  characteristic  of  Petri  nets  is  that  they 
capture  the  dynamic  behavioral  characteristics  of  systems  being 
modeled.  In  addition  to  graphical  notation,  Petri  nets  also  come  with 
a  significant  body  of  mathematical  formalism. 
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Process  Automation  Tools.  Process  automation  tools  provide  a  way  to 
integrate  people  and  methods  in  a  software  development  organization.  There 
is  currently  little  practical  day-to-day  experience  with  this  emerging 
technology.  However,  its  maturation  promises  to  enhance  process 
improvement.  Some  of  the  tools  being  researched  for  process  automation 
include  Process  Weaver,  Synervision,  and  Statemate. 


8.9  Process  Measurement 

Process  measurement  is  used  to  identify  candidate  processes  for  improvement  and  to  track 
process  improvement  efforts.  Defining  key  measurement  points  and  deriving  quantifiable 
proof  of  process  improvement  are  the  reasons  for  measurements. 

Metrics  paradigms.  Basili's  Goal-Question-Metric  (G-Q-M)  framework 
provides  a  tool  for  organizations  to  decide  which  measurements  to  collect.  It 
links  process  goals  with  the  critical  questions  that  must  be  answered  to 
achieve  the  goals,  and  identifies  data  items  needed  to  collect  measurement 
[Basili  84]. 

Checklists  approach.  The  SEI  has  developed  an  approach  for  design  and 
implementation  of  a  measurement  program  based  on  a  checklist  paradigm 
and  Basili’s  Goal-Question-Metric  framework. 

Size  planning  concepts.  Tools  used  to  estimate  size  at  the  early  stage  of 
requirements  definition  are:  Fuzzy-Logic,  Function-Point,  Standard- 
Component,  Change  Sizing. 

Cost  estimating  models.  There  are  a  number  of  models  available  to 
estimate  software  cost,  including:  induction  models,  parametric  models, 
COCOMO,  SLIM,  PRICE,  function  points,  ESTIMACS. 

Metrics  baseline.  The  four  core  measures  of  software  are  size,  effort, 
schedule,  and  quality.  Size  is  measured  in  terms  of  lines  of  code  or  function 
point.  Effort  is  expressed  in  terms  of  staff  hours  or  dollars.  Schedule  is 
expressed  in  terms  of  time  (days,  weeks,  months,  or  years).  Quality  is 
expressed  (in  a  narrow  sense)  in  terms  of  defects:  the  lower  the  number  of 
defects  the  higher  the  quality  of  the  software.  Software  quality  generally  deals 
with  many  more  attributes  than  just  defects. 

Quality  attributes.  Quality  attributes  are  determined  by  audits,  reviews, 
trouble  reports,  and  defect  detection.  Quality  factors  include  functionality, 
usability,  reliability,  maintainability,  supportability. 
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9  Pervasive  Supporting  Skills 

In  this  section  we  describe  general  skills  that  can  be  applied  in  many  process  improvement 
situations  and  activities.  Sometimes  referred  to  as  people  skills,  many  of  these  areas  form  a 
necessary  foundation  for  the  quality  culture  described  in  Section  7.  Our  customers,  through 
surveys  and  focus  groups,  have  cited  people-related  skills  as  a  major  area  in  which  organiza¬ 
tions  need  competency  in  order  to  effect  process  improvement. 

“People  don’t  know  how  to  address  human  issues,  or  don’t  even  acknowledge 
human  issues  are  there.” — customer  view 

9.1  Teamwork  Skills 

“Organize  as  much  as  possible  around  teams,  to  achieve  enhanced  focus,  task 
orientation,  innovativeness,  and  individual  commitment.  ”  — Tom  Peters 

“As  organizations  become  more  involved  in  the  quality  movement,  they 
discover  the  benefits  of  having  people  at  all  levels  work  together  in  teams.” 

— The  Team  Handbook 

The  process  improvement  infrastructure  involves  many  teams:  the  steering  committee,  the 
process  group,  and  process  action  teams.  Teamwork  skills  are  an  essential  part  of  process 
improvement,  and  teamwork  forms  one  of  the  bases  of  a  quality  culture.  Selected  teamwork 
topics  are  described  below,  and  the  references  offer  elaboration. 

9.1.1  Managing  Group  Processes 

Whether  they  are  called  quality  circles,  semi-autonomous  work  groups,  self-directed  teams,  or 
self-managing  teams,  teams  are  groups  of  people  working  together.  Teams  use  group  pro¬ 
cesses,  meet  in  group  sessions,  and  behave  to  maximize  group  participation  and  contribution. 

Ingredients  for  a  successful  team.  Clarity  in  team  goals,  an  improvement 
plan,  clearly  defined  roles,  clear  communication,  beneficial  team  behaviors, 
well-defined  decision  procedures,  balanced  participation,  established  ground 
rules,  awareness  of  the  group  process,  use  of  the  scientific  approach. 

Planning  group  sessions.  Purpose  and  desired  outcome;  is  a  group 
needed?  Who  should  attend?  Gauging  group  chemistry;  agenda  building; 
meeting  roles. 

Planning  the  group  process.  Getting  people  involved;  sharing  and 
processing  group  information;  group  presentations;  subgroup  work. 

Group  task  behaviors.  Proposing,  building,  information  seeking,  opinion 
seeking,  information  giving,  opinion  giving,  disagreeing,  summarizing,  testing 
comprehension,  consensus  building. 

Group  maintenance  behaviors.  Encouraging,  harmonizing,  performance 
checking,  standard  setting,  tension  relieving. 
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Gate-keeping  processes.  Regulating  group  participation  by  bringing  in  and 
shutting  out. 

Team  selection.  Cross-functional  teams. 

Team  roles.  Leader,  facilitator,  technical  expert,  quality  advisor,  team 
members,  enabler;  role  assignments;  role  switching;  role  sharing. 

Facilitation.  Focusing,  stimulating  contributions,  dealing  with  disruptive 
behavior. 

Team  performance  assessment.  Rewarding  collaborative  teamwork. 

9.1.2  Team  Building 

Teams  progress  through  various  phases  as  they  develop  and  grow.  Two  models  are  described 
below. 


Stages  of  Team  Growth.  Forming  (transition  from  individual  to  team 
member);  Storming  (resistance,  defensiveness,  competitiveness);  Norming 
(reconciliation,  establishing  and  accepting  ground  rules,  cohesiveness,  trust); 
Performing  (team  understanding,  satisfaction,  constructive  self-change, 
ability  to  prevent  or  work  through  group  problems,  closeness)  [Scholtes  88]. 

Team  Performance  Model.  Orientation  (Why  am  I  here?);  Trust  Building 
(Who  are  you?);  Goal/Role  Clarification  (What  are  we  doing?);  Commitment 
(How  will  we  do  it?);  Implementation  (Who  does  what,  when,  where?);  High 
Performance  (Wow!);  Renewal  (Why  continue?)  [Drexler  92]. 

9.1.3  Team  Dynamics 

Teams  must  learn  to  work  together  and  support  each  other.  They  must  interact  constructively 
and  resolve  group  conflicts. 

Dealing  with  emotions.  Acknowledging  feelings;  processing  feelings; 
refocusing  on  outcomes. 

Guidelines  for  constructive  feedback.  Acknowledge  the  need  for 
feedback,  give  both  positive  and  negative  feedback,  understand  the  context, 
know  when  to  give  feedback,  know  how  to  give  feedback,  know  how  to 
receive  feedback. 

Working  through  group  problems.  Methods:  off-line  conversation, 
impersonal  group  time,  off-line  confrontation,  in-group  confrontation; 
negotiation;  conflict  resolution. 

9.1.4  Group  Decision  Making  Techniques 

Several  decision  making  approaches  are  possible  such  as  autocratic  (leader  decides),  collab¬ 
orative  (group  discusses,  leader  decides),  delegative  (decision  is  delegated),  and  consensus. 

Consensus  is  reached  when  there  is  a  group  decision  that  all  members  can  support  and  no 
member  opposes.  Each  person  understands  the  decision,  has  had  a  chance  to  express  his  or 
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her  view,  and  states  willingness  to  support  the  decision.  There  are  several  techniques  that  can 
be  used  to  reach  consensus. 

Brainstorming  and  multivoting.  Brainstorming:  define  the  topic;  think 
silently;  call  out  ideas  (no  discussion);  capture  list  of  items  generated. 
Multivoting:  combine  similar  items;  allow  members  to  choose  up  to  1/3  of  the 
items  for  consideration;  repeat  until  only  a  few  items  remain. 

Nominal  Group  Technique.  Brainstorm  to  generate  ideas,  clarify  and 
discuss;  multivote  to  reduce  list  to  50  or  fewer  items;  vote  by  assigning  a  point 
value  to  each  item  ranging  from  highest  preference  to  lowest,  highest  value 
is  4  for  up  to  20  items,  6  for  20-35,  8  for  35-50  items,  tally  the  votes,  highest 
is  the  group’s  choice. 

List  reduction.  Using  filters  (criteria)  to  shorten  a  list  of  ideas;  balance  sheets 
to  identify  and  review  pro’s  and  con’s  of  ideas;  force  field  analysis. 

Rating  systems.  Criteria  rating  forms;  rating  the  criteria;  applying  criteria  to 
problems  or  solutions;  point  scoring  systems;  weighted  voting;  paired 
comparisons. 

Analytical  hierarchy  process.  A  tool  to  establish  and  prioritize  goals, 
objectives,  and  alternatives  [Saaty  80]. 

9.2  Communication  Skills 

“communications ...  a  vital  process  for  promoting  organizational  learning, 
improvement,  and  change” — Mary  Young  and  James  E.  Post 

Communication  is  another  key  aspect  of  a  successful  process  improvement  effort.  It  is  not  only 
essential  for  carrying  out  process  improvement  activities,  but  open  communication  is  a  feature 
of  a  quality  oriented  corporate  culture. 

Communication  involves  exchange  of  information.  Both  sender  and  receiver  have  responsibil¬ 
ities  to  ensure  the  information  is  correctly  understood.  Communication  occurs  at  several  lev¬ 
els:  corporate,  team,  and  interpersonal. 

9.2.1  Corporate  Communication 

Principles  of  effective  corporate  communications.  Chief  executive  as 
communications  champion;  matching  actions  and  words;  commitment  to  two- 
way  communication;  face-to-face  communication;  shared  responsibility  for 
employee  communications;  dealing  with  bad  news;  customers,  clients,  and 
audiences. 

Communications  strategy.  Communicate  not  only  what,  but  why  and  how; 
timeliness;  communicate  continuously;  link  the  “big”  picture  with  the  “little 
picture”;  don’t  dictate  the  way  people  should  feel  about  the  news;  uncover  and 
remove  barriers  to  communication. 
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Communications  as  a  process  (not  a  product).  Send,  encode,  transmit  across 
channel,  decode,  receive;  feedback  loops. 

Communication  channels.  Videos,  electronic  mail,  publications,  television; 
writing,  pictures,  newsletters;  formal  or  informal;  written  or  oral. 

Techniques.  Opinion  surveys,  attitude  surveys;  techniques  for  effective 
communication  of  a  vision. 

Institutionalizing  communications  policies.  Training,  coaching,  goal¬ 
setting,  evaluation,  reward,  responsibility  to  communicate  problems; 
establishing  ground  rules  for  surfacing  and  dealing  with  conflict. 

9.2.2  Team  Communication 

These  guidelines  allow  for  clarity  of  discussions  and  information  passing  in  team  situations. 

Speaking.  Speaking  clearly  and  directly  (e.g.  avoid  using  questions  to 
disguise  statements);  being  succinct  without  long  anecdotes  or  examples. 

Listening.  Listening  actively,  exploring  ideas. 

Sharing  information  on  many  levels.  Sensing  statement,  thinking 
statement,  feeling  statement,  statements  of  intentions,  statement  of  actions. 

Effective  discussion  skills.  Ask  for  clarification,  act  as  gatekeepers  to 
encourage  group  participation,  listen  and  actively  explore  ideas,  summarize 
and  restate,  contain  digression,  manage  time,  end  the  discussion  when 
nothing  further  to  be  gained,  test  for  consensus,  evaluate  the  quality  of  the 
discussion. 

9.2.3  Interpersonal  Communication 

At  the  individual  level,  effective  communication  ensures  information  is  mutually  understood 
and  openly  shared. 

An  individual  needs  writing  skills,  presentation  skills,  persuasion,  active 
listening,  questioning,  body  language,  constructive  criticism,  conflict 
resolution,  self  awareness. 


9.3  Interaction  Skills 

“Help  people  come  to  grips  with  human  issues.” — customer  view 

We  capture  here  some  skills  used  in  everyday  human  interaction.  Deimel  describes  early  work 
in  developing  working  models  that  facilitate  mastery  of  human  interaction  capabilities  [Deimel 
94], 


Interpersonal  skills.  Networking,  negotiating,  leadership,  expediting,  tact, 
being  part  of  the  solution  and  not  part  of  the  problem,  confrontation. 

Human  dynamics.  Mental,  emotional,  and  physical  principles;  self- 
knowledge;  different  personality  dynamics;  human  behavior  models. 
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Human  interaction  capabilities  [Deimel  94]: 

skills:  receptive  communication,  expressive  communication,  negotiation, 
collaboration,  conflict  management,  decision  making 

activities:  Teamwork,  meetings,  interviews,  presentations,  planning  ses¬ 
sions,  reviews,  training 

human  interaction  capability  model— predominant  relating  styles: 

power  differential/self-interest;  formal  protocol/enforcement;  formal  ro¬ 
les/team  play;  dynamic  roles/public  data;  synergistic  roles/shared  goals 

human  interaction  capability  model— group  attitudes:  denial/co-de- 
pendency;  awakening;  awareness;  confidence;  certainty 


9.4  Consulting  Skills 

“A  consultant  is  a  person  in  a  position  to  have  some  influence  over  an 
individual,  a  group,  or  an  organization,  but  who  has  no  direct  power  to  make 
changes  or  implement  programs."  — Peter  Block 

People  working  on  process  improvement  frequently  act  as  consultants  and  consulting  skills 
become  essential  for  influencing  decision  makers  [CSW]. 

Phases  of  consulting: 

entry,  sensing,  and  relationship  building:  listening,  building  a  trusting 
relationship,  probing;  referral  mechanisms;  questioning,  advising,  reflect¬ 
ing,  interpreting,  self-disclosing,  silence 

contracting:  explicit  agreement  on  mutual  expectations,  explicit  agree¬ 
ment  on  working  arrangement;  essential  wants  and  desirable  wants;  plan¬ 
ning  a  contracting  meeting;  sample  contract  contents:  goals,  scope,  team, 
roles,  process,  anonymity/confidentiality,  termination,  resources;  renego¬ 
tiation 

data  gathering,  diagnosis,  and  feedback:  data  collection,  analysis,  pre¬ 
sentation,  decision  making;  interviews,  questionnaires,  observation,  his¬ 
torical,  sampling;  data  reduction,  graphic  presentation 

planning,  execution,  and  monitoring:  develop  project  and  monitoring 
mechanisms;  select  project  planning  method,  milestones,  resources, 
commitment;  execute  and  monitor  plan;  types  of  plans  (strategic,  tactical, 
operational);  planning  tools  (Pert,  Gantt,  CPM);  actions  and  outcomes 
(best  case,  worst  case);  checkpoints  (milestones,  recontracting  points) 
renegotiation  strategy;  replanning 

evaluation  and  consultant  feedback:  effectiveness  of  consultant,  les¬ 
sons  learned,  extent  to  which  project  objectives  met,  post-project  sur¬ 
veys;  managing  feedback  meetings 


CMU/SEI-95-TR-003 


77 


termination:  exchange  feedback  and  terminate;  leaving  with  a  good  re¬ 
lationship 

Authenticity  skills.  Making  “I”  statements;  stating  present  feelings; 
describing  in  a  nonevaluative  way;  changing  thoughts  into  statements. 

Client  resistance.  Common  forms  of  resistance;  handling  the  resistance: 
pick  up  the  clues,  name  the  resistance  in  neutral  language,  make  an  authentic 
“I”  statement,  let  the  client  respond. 

Consultant  roles.  Technical  expert,  process  facilitator;  collaboration  with 
client  regarding  roles  of:  objective  observer,  process  counselor,  fact  finder, 
identifier  of  alternatives  and  linker  of  resources,  joint  problem  solver, 
trainer/educator,  information  specialist,  advocate. 


9.5  Behavioral  Change  Skills 

“We  use  two  approaches  to  move  our  culture  towards  new  ideas:  change 
behaviors  to  change  attitudes  and  change  attitudes  to  change  behaviors." 
— SEPG  member 


Social  Behavior.  Understanding  and  dealing  with  different  types  of  social 
behavior  [Forsha  92]. 

mounting  behaviors  (expressing  dominance  and  control):  back  stab¬ 
bing,  sniping,  back-shooting,  bullying,  gatekeeping,  back  burner 

grooming  behaviors  (extending  friendship,  warmth,  and  cooperation): 
Compliment,  consideration,  facilitation,  integrity 

manipulative  behaviors:  Alligator  (rage),  assumption,  hidden  agenda, 
lip  service 

Transactional  analysis.  Ego  states:  parent,  child,  adult;  Karpman  Drama 
Triangle:  persecutor,  victim,  rescuer;  games  people  play  [Harris  69]. 

Strategies.  Conflict  resolution;  constructive  criticism;  negotiation; 
contracting;  managing  stress;  behavioral  modeling;  Aikado:  using  opponent’s 
energy;  knowing  how  to  sell;  reframing. 

Rewards  and  recognitions.  Identifying  intrinsic  and  extrinsic  rewards; 
informal  and  formal  reinforcement  mechanisms. 

Self-awareness  instruments.  Myers-Briggs  Type  Indicator  [Kroeger  92V 
Wilson  Learning. 

Coaching.  Coaching  is  a  process  for  transferring  knowledge,  skills,  and/or 
values  and  attitudes  from  the  coach  to  the  learner  so  that  learner  is  enabled 
or  empowered  to  perform  new  or  increasingly  more  complex  tasks  [Mink  93], 
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Conclusions 


10.1  Tailoring  Considerations 

This  report  has  presented  subject  matter  of  the  process  improvement  area.  It  has  not  indicated 
who  must  know  what  or  to  what  extent.  Process  improvement  requires  teams  of  professionals 
with  a  diversity  of  knowledge,  skills,  and  attributes.  The  synergy  of  individual  competencies 
covering  the  broad  range  of  topic  areas  described  here  is  what  will  affect  process  improve¬ 
ment.  To  be  effective  however,  certain  fundamentals  must  be  comprehended  and  shared  by 
all. 

Selecting  subsets  of  the  process  improvement  subject  matter  for  specific  audiences  is  prima¬ 
rily  the  responsibility  of  curriculum  designers  and  skills  analysts  and  we  envision  ongoing  work 
to  develop,  gather,  and  disseminate  recommendations  from  different  contexts  and  domains. 
However,  we  offer  some  brief  tailoring  considerations  here. 

The  subject  matter  may  be  tailored  by  general  audience  category.  Table  5  depicts  sample  au¬ 
diences  for  acquiring  knowledge  and  skills  across  academic  and  industrial  domains. 


Table  5:  General  Audience  Classification  with  Sample  Audiences  in  Different  Domains 


General  Audience 
Category 

Academic  Domain 

Industry/government 

Domain 

Managers:  Strategic  and 
Tactical 

Engineering  Management 
Specialty  students 

Chief  Executive  Officers 
Software  Managers 
Management  Steering 
Committees 

Sponsors 

Managers:  Operational 

All  undergraduate  and  grad¬ 
uate  students  (core) 

Project  Managers 

Process  Owners 

Process  Specialists 

Process  Engineering  Spe¬ 
cialty  students 

Quality  Improvement  Spe¬ 
cialty  students 

SEPG  Members 

Change  Agents 

Champions 

Practitioners 

All  undergraduate  and  grad¬ 
uate  students  (core) 

Process  Action  Teams 
Software  Engineers 

Support  Specialties 

Everybody 
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Using  this  general  audience  breakdown,  we  consider  a  very  rough  identification  of  which  sub¬ 
ject  matter  areas  are  most  pertinent  for  which  audience,  and  what  extent  of  mastery  might  be 
required.  In  Table  6,  each  “x”  represents  more  competency  in  the  topic  area,  ranging  from  “x” 
(general  knowledge  and  competency)  to  “xxx”  (in-depth  mastery). 


Table  6:  Aligning  Subject  Matter  with  General  Audiences 


Topic  Areas 

Audience 

Managers 

Strategic 

and 

Tactical 

Managers 

Opera¬ 

tional 

Process 

Specialists 

Practi¬ 

tioners 

Section  4:  Process  Funda¬ 
mentals 

4.1  General  Concepts 

XX 

XX 

xxx 

XX 

4.2  Process  Maturity  Concepts 

XX 

XX 

xxx 

XX 

4.3  Process  Development  and 
Enactment  Concepts 

XX 

XX 

xxx 

XX 

4.4  Process  Modeling 

Concepts 

XX 

XX 

xxx 

XX 

4.5  Process  Definition 

Concepts 

XX 

XX 

xxx 

XX 

4.6  Software  Process 
Measurement 

XX 

XX 

xxx 

XX 

4.7  Software  Engineering 
Processes 

XX 

xxx 

xxx 

xxx 

Section  5:  Process  Improve¬ 
ment  Fundamentals 

5.1  Concepts  and  Principles 

xxx 

xxx 

xxx 

xxx 

5.2  The  Seeds  of  Process 
Improvement 

xxx 

xxx 

xxx 

XX 

5.3  Improvement  Models  and 
Standards 

xxx 

XX 

xxx 

X 

5.4  Process  Appraisal 

XX 

XX 

xxx 

X 

5.5  Improvement  Approaches: 
Organizational  Level 

xxx 

XX 

xxx 

X 
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Table  6:  Aligning  Subject  Matter  with  General  Audience 


• 

Topic  Areas 

Managers 

Strategic 

and 

Tactical 

Managers 

Opera¬ 

tional 

Process 

Specialists 

Practi¬ 

tioners 

5.6  Improvement  Approaches: 
Process  Level 

XX 

XX 

XXX 

XX 

5.7  Improvement  Approaches: 
Individual  Level 

XXX 

XXX 

XXX 

XXX 

Section  6:  Process  and 
Process  Improvement 
Management 

6.1  Process  Improvement 
Management 

XXX 

XXX 

XXX 

XX 

6.2  Process  Management 

XX 

XXX 

XXX 

XXX 

6.3  Organizational  Process 
Management 

XXX 

XX 

XXX 

XX 

Section  7:  Culture  Change 

7.1  Directions 

XXX 

XXX 

XXX 

XXX 

7.2  Change  Concepts 

XX 

XX 

XXX 

XX 

7.3  Change  Strategies 

XX 

X 

XXX 

X 

Section  8:  Process 
Improvement  Tools  and 
Techniques 

8.1  Customer  Value 

XXX 

XXX 

XXX 

XXX 

8.2  Problem  Solving 

XXX 

XXX 

XXX 

XXX 

8.3  Statistical  Techniques 

XX 

XX 

XXX 

XXX 

8.4  Cost/Benefit  Analysis 

XXX 

XX 

XXX 

XX 

8.5  Risk  Assessment 

XXX 

XXX 

XXX 

XX 

8.6  Defect  Detection  and 
Prevention 

X 

X 

XXX 

XXX 

8.7  Benchmarking 

X 

XX 

XXX 

XX 

8.8  Process  Definition 

X 

XX 

XXX 

XXX 

8.9  Process  Measurement 

X 

XX 

XXX 

XXX 
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Table  6:  Aligning  Subject  Matter  with  General  Audience 


Topic  Areas 

Audience 

Managers 

Strategic 

and 

Tactical 

Managers 

Opera¬ 

tional 

Process 

Specialists 

Practi¬ 

tioners 

Section  9:  Pervasive  Sup¬ 
porting  Skills 

9.1  Teamwork  Skills 

XXX 

XXX 

XXX 

XXX 

9.2  Communication  Skills 

XXX 

XXX 

XXX 

XXX 

9.3  Interaction  Skills 

XXX 

XXX 

XXX 

XXX 

9.4  Consulting  Skills 

XXX 

XXX 

XXX 

XX 

9.5  Behavioral  Change  Skills 

XX 

XX 

XXX 

XX 

10.2  Delivery  Considerations 

The  subject  matter  of  process  improvement  is  interdisciplinary  in  nature,  and  we  envision  de¬ 
livery  of  this  material  to  be  carried  out  through  collaborative  efforts. 

In  academia,  several  departments  might  be  involved.  For  example,  besides  being  taught  by 
software  engineering  and  computer  science  faculty,  some  topics  may  be  taught  in  manage¬ 
ment,  statistics,  economics,  industrial  psychology,  or  other  social  science  departments.  Indus¬ 
try  experts  and  quality  consultants  could  augment  regular  course  offerings. 

In  industry  and  government,  collaboration  with  universities,  consultants,  and  other  organiza¬ 
tions  may  help  meet  education/training  delivery  requirements. 

As  this  subject  area  continues  to  mature,  we  anticipate  that  supporting  materials  will  continue 
to  be  developed  and  disseminated  to  assist  teaching  and  learning  about  process  improve¬ 
ment. 

1 0.3  Next  Steps 

This  report  is  an  initial  compilation  of  information  from  a  rapidly  advancing  field.  We  envision 
compiling  or  developing  supporting  educational  materials  for  these  topic  areas  at  a  later  time. 
These  may  be  in  the  form  of  curriculum  models,  detailed  course  syllabi,  course  notes,  courses, 
curriculum  modules,  annotated  bibliographies,  best  practice  reports,  or  other  guidelines. 
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Contact  Information,  on  page  vii,  gives  the  address  through  which  readers  can  send  us  inputs 
for  enhancement,  improvement,  and  further  work  in  this  area.  We  welcome  your  views. 

“< Over  the  long  run,  superior  performance  depends  on  superior  learning.” 

— Peter  Senge 
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Appendix  B  Contributors,  Feedback  from  the 

Field,  and  Reviewers 

B.1  Survey  on  Capability  Maturity  Model  for  Software  (CMM)- 
Based  Education  and  Training 

This  survey  was  carried  out  in  1992  and  1993.  The  purpose  was  to  contact  a  broad  base  of 
SEI  customers  and  elicit  their  views  and  concerns  regarding  several  aspects  of  process  im¬ 
provement.  This  information  has  helped  in  the  preparation  and  validation  of  some  of  the  ma¬ 
terial  in  this  report.  Eighty-one  responses  were  received.  Respondents  included  subsets  of 
Software  Capability  Evaluation  (SCE)  Workshop  attendees,  SEI  Resident  Affiliates,  1992  SEI 
Symposium  attendees,  participants  in  the  6th  Conference  on  Software  Engineering  Education, 
West  Coast  Software  Process  Improvement  Network  (SPIN)  members,  Capability  Maturity 
Model  (CMM)  Advisory  Board  members,  participants  in  SEI’s  Software  Project  Management 
and  Software  Productivity  Improvement  courses,  government  contacts  provided  by  SEI  staff 
members,  and  SEI  reviewers/consultants  [Ibrahim  93a]. 

B.2  Software  Process  Improvement  Curriculum:  Birds-of-a- 
Feather  Participants 

A  birds-of-a-feather  session  on  “Software  Process  Improvement  Curriculum”  was  held  at  the 
7th  Conference  on  Software  Engineering  Education  (CSEE)  in  January  1 994  in  San  Antonio, 
Texas.  This  session,  led  by  Ron  Radice  and  Linda  Ibrahim,  focused  on  discussing  issues  and 
topics  that  might  be  addressed  in  software  process  improvement  education  and  training.  A 
survey  was  conducted  eliciting  participants’  views  on  topic  areas  and  their  relative  importance 
for  different  audiences.  The  individuals  in  Table  7  participated  in  that  session. 


Table  7:  Birds-of-a-Feather  Participants 


Name 

Affiliation 

Ted  Ahmanson 

Bell  Atlantic 

Shahrzad  Amirsoleymani 

Moorhead  State  University 

Don  Bagert 

Texas  Tech  University 

Stefan  Biffl 

Technical  University  of  Vienna  -  Austria 

Maribeth  Carpenter 

SEI 

Marcus  Deininger 

University  of  Stuttgart,  Germany 

Janet  Drake 

University  of  Northern  Iowa 

Norm  Gibbs 

SEI 
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Table  7:  BoF  Participants 


Name 

Affiliation 

Thomas  Hilburn 

Embry-Riddle  Aeronautical  University 

Iraj  Hirmanpour 

Embry-Riddle  Aeronautical  University 

Soheil  Khajenoori 

Embry-Riddle  Aeronautical  University 

Peter  Knoke 

University  of  Alaska- Fairbanks 

Russ  McGuire 

Cerner  Corporation 

Nancy  Mead 

SEI 

Frederic  J.  Mowle 

Purdue  University 

Pierre  N.  Robillard 

Ecole  Polytechnique  -  Montreal,  Canada 

Aboalfazl  Salimi 

Embry-Riddle  Aeronautical  University 

Carol  Sledge 

SEI 

Massood  Towhidnejad 

Embry-Riddle  Aeronautical  University 

Laurie  Werth 

University  of  Texas  at  Austin 

Sascha  Zumbusch 

Contributed  Software  -  Berlin,  Germany 

B.3  Informal  Questionnaire  on  Topic  Areas 

In  the  summer  of  1994  an  informal  survey  was  conducted  via  selected  bboards  and  email  lists 
asking  for  views  regarding  knowledge  and  skills  required  for  process  improvement.  The  sur¬ 
vey  asked  for  ideas  and  thoughts  along  the  following  lines: 

Topic:  Briefly  describe  a  topic  area  you  believe  is  important  to  be 
knowledgeable  about  in  order  to  effect  process  improvement.  Topics  may 
range  from  broad  concepts  to  specific  skill  areas. 

Objective:  Please  indicate  the  reason  you  need  knowledge  of  these 
concepts  or  mastery  of  these  skills  in  the  context  of  process  improvement. 

Importance:  Please  indicate  whether  you  believe  this  is  an  “essential”  topic 
or  a  “desirable”  topic  for  process  improvement  education  and  training. 

The  individuals  in  Table  8  provided  their  thoughts  and  perspectives: 
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Table  8:  Contributors  Regarding  Topic  Areas 


Name 

Affiliation 

Judy  Bamburger 

- 

Richard  Botting 

California  State  University 

Jim  Cardow 

TYBRIN  Corporation 

Janet  Chamberlain 

- 

Mike  Connelly 

Tandem  Computers,  Inc. 

Margie  Davis 

ADP  Dealer  Services 

Dennis  Frailey 

- 

Gary  Gaston 

Lockheed  -  Ft.  Worth  Co. 

Terry  Hinton 

University  of  Surrey  (England) 

Arto  Jarvinen 

SoftLab  ab  (Sweden) 

Sanjeev  N.  Khadilkar 

Motorola  India  Electronics  (Pvt.)  Ltd. 

Mike  Kirby 

Xerox  Corporation 

Jean  M.  MacLoed 

Hewlett-Packard  Co. 

Pete  Malpass 

SEI 

Mike  Mattison 

SEI 

David  E.  McConnell 

Naval  Surface  Warfare  Center,  Dahlgren 
Division 

Mike  McCracken 

Georgia  Institute  of  Technology 

Julia  L.  Mullaney 

Union  Switch  and  Signal,  Inc. 

Mark  Paulk 

SEI 

Margaret  A.  Ramsey 

Software  Process  Innovators 

Hal  Render 

University  of  Colorado  at  Colorado 

Springs 

Joe  Sanders 

Centre  for  Software  Engineering  (Ireland) 

Walt  Scacchi 

University  of  Southern  California 

Barry  Shostak 

CAE  Electronics  Ltd. 

Peter  Spool 

Siemens  Corporate  Research,  Inc. 

Steve  Wilkinson 

Tandem  Computers,  Inc. 
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B.4  Symposium  Focus  Group 

In  August  1994  a  focus  group  regarding  “Knowledge  and  Skills  for  Process  Improvement”  was 
held  in  conjunction  with  the  SEI  Symposium.  The  group  focused  on  answering  the  following 
question:  “What  are  the  main  topics  you  have  found  necessary  to  know  about  or  be  skilled  at 
in  order  to  effect  process  improvement?”  Additional  discussion  ensued  regarding  subtopics 
within  these  topics,  audience  for  the  subject  areas,  and  the  scope  of  process  improvement  for 
the  purposes  of  this  report. 

Linda  Ibrahim  and  Iraj  Hirmanpour  facilitated  this  session,  and  the  people  in  Table  9 
participated: 


Table  9:  Focus  Group  Attendees 


Name 

Affiliation 

Neil  Adams 

Mitre  Corp. 

Maribeth  Carpenter 

SEI 

Pat  Delohery 

HBO  &  Co. 

Libby  Dunn 

Reliance  Comm/Tec  Transmission  Systems 

Pat  Ferguson 

Advanced  Information  Systems 

David  E.  McConnell 

Naval  Surface  Warfare  Center,  Dahlgren 
Division 

Bob  McFeeley 

SEI 

Dave  Moore 

RWD  Technologies,  Inc. 

Paula  Moore 

National  Oceanic  &  Atmospheric  Adminis¬ 
tration,  Dept.  Of  Commerce 

Chuck  Myers 

SEI 

Jeff  O’Neil 

PRC  Inc. 

Jerome  Pesant 

Applied  Software  Engineering  Centre  (Can¬ 
ada) 

David  K.  Smith 

Navy  Fleet  Material  Support  Office 

Joyce  Statz 

TeraQuest  Metrics,  Inc. 

Michael  Stinson 

SEI,  Central  Michigan  University 

Sarah  Sullivan 

Louise  Williams 

CACI 

- - - — - — - - 
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B.5  Reviewers 

This  report  was  reviewed  internally  for  early  drafts,  internally  and  externally  for  an  intermediary 
draft,  and  internally  for  the  final  draft.  The  reviewers  in  Table  10  participated. 

Table  10:  Reviewers 


Name 


Clark  Archer 


Judy  Bamberger 


Peter  Capell 


Maribeth  Carpenter 


Bill  Curtis 


Robert  Daniel 


Margie  Davis 


Betty  Deimel 


Suzanne  Garcia 


Joe  Giannuzzi 


John  Goodenough 


Dan  Green 


Jon  Gross 


Bill  Hefley 


Fred  Hueber 


Watts  Humphrey 


Patricia  Hurst 


Soheil  Khajenoori 


Mark  Kusanic 


Walt  Lamia 


Beth  Leber 


John  Maher 


David  McConnell 


Bob  McFeeley 


Affiliation 


SEI,  Winthrop  University 


GeoQuest  Data  Management 


ADP  Dealer  Services 


SEI,  Defence  Contract  Management 
Command 


Fastrak  Training  Inc. 


Embry  Riddle  Aeronautical  University 


Naval  Surface  Warfare  Center,  Dahlgren 
Division 


Table  10:  Reviewers 


Name 

Affiliation 

Nancy  Mead 

SEI 

Bill  Peterson 

SEI 

Dick  Phillips 

SEI 

Ron  Radice 

SEI,  Software  Technology  Transition 

Russ  Reed 

SEI,  Sematech 

Barry  Shostak 

CAE  Electronics  Ltd.  (Canada) 

Becky  Smith 

RebL  Systems 

Mary  Ellen  Steibel 

Delph  Information  Systems 

Jim  Stewart 

SEI,  Nuclear  Regulatory  Commission 

Mike  Stinson 

SEI,  Central  Michigan  University 

Sarah  Sullivan 

- 

Carol  Ulrich 

SEI 

Laurie  Werth 

University  of  Texas,  Austin 

Rosie  Wood 

Stability,  Inc. 

Janet  Yodanis 

SEI 

Dave  Zubrow 

SEI 

142 


CMU/SEI-95-TR-003 


Appendix  C  Improving  the  Education  Process 

“Institute  a  vigorous  program  of  education  and  self-improvement.” — W.  E. 

Deming 

Models  and  standards  for  improvement  frequently  include  a  process  or  process  area  dealing 
with  education  and  training.  Selected  extracts  from  such  guidelines  are  offered  in  this  section 
in  order  to  provide  special  focus  on  the  educational  process  and  its  improvement. 


C.1  CMM-Defined  Level  Key  Process  Area  “Training 
Program” 

Purpose:  to  develop  the  skills  and  knowledge  of  individuals  so  they  can  perform  their  roles 
effectively  and  efficiently 

Goals:  Training  activities  are  planned.  Training  for  developing  the  skills  and  knowledge  need¬ 
ed  to  perform  software  management  and  technical  roles  is  provided.  Individuals  in  the  soft¬ 
ware  engineering  group  and  software-related  groups  receive  the  training  necessary  to  perform 
their  roles.  The  key  practices  to  accomplish  these  goals  are  as  follows: 

Commitment  to  perform:  The  organization  follows  a  written  policy  for 
meeting  its  training  needs. 

Ability  to  perform:  A  group  responsible  for  fulfilling  the  training  needs  of  the 
organization  exists.  Adequate  resources  and  funding  are  provided  for 
implementing  the  training  program.  Members  of  the  training  group  have  the 
necessary  skills  and  knowledge  to  perform  their  training  activities  (e.g. 
training  in  instructional  techniques,  refresher  training  in  the  subject  matter). 

Activities  performed:  Each  software  project  develops  and  maintains  a 
training  plan  that  specifies  its  training  needs.  The  organization’s  training  plan 
is  developed  and  revised  according  to  a  documented  procedure.  The  training 
for  the  organization  is  performed  in  accordance  with  the  organization’s 
training  plan.  Training  courses  prepared  at  the  organization  level  are 
developed  and  maintained  according  to  organization  standards.  A  waiver 
procedure  for  required  training  is  established  and  used  to  determine  whether 
individuals  already  possess  the  knowledge  and  skills  required  to  perform  in 
their  designated  roles.  Records  of  training  are  maintained. 

Measurement  and  analysis:  Measurements  are  made  and  used  to 
determine  the  status  of  the  training  program  activities.  Measurements  are 
made  and  used  to  determine  the  quality  of  the  training  program. 

Verifying  implementation:  The  training  program  activities  are  reviewed  with 
senior  management  on  a  periodic  basis.  The  training  program  is 
independently  evaluated  on  a  periodic  basis  for  consistency  with,  and 
relevance  to,  the  organization’s  needs.  The  training  program  activities  and 
work  products  are  reviewed  and/or  audited  and  the  results  are  reported. 
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Source:  Paulk;  Weber;  Garcia;  Chrissis;  &  Bush.  Key  Practices  of  the  Capability  Maturity  Mod¬ 
el,  Version  1.1  (CMU/SEI-93-TR-25,  ADA263432).  Pittsburgh,  Pa.:  Software  Engineering  In¬ 
stitute,  Carnegie  mellon  University,  1993. 

C.2  SPICE  Organization  Process  Category  Process: 

“Perform  Training” 

Purpose:  to  provide  the  organization  and  projects  with  individuals  who  possess  the  needed 
skills  and  knowledge  to  perform  their  roles  effectively.  The  base  practices  that  address  this 
purpose  are: 

Identify  common  training  needs  across  the  organization  based  on 
organizational  and  project  inputs  to  build  the  knowledge  and  skills  of  the  staff. 

Develop  or  acquire  training  that  addresses  the  common  training  needs. 

Train  personnel  to  have  the  knowledge  and  skills  needed  to  perform  their 
roles. 

Maintain  appropriate  records  of  training  and  experience  for  the  staff. 


Source:  SPICE  BPG  Version  1.00,  September  1994. 

C.3  Malcolm  Baldrige  National  Quality  Award  Criteria  - 
Employee  Education  and  Training 

Areas  to  Address: 

how  the  company  determines  needs  for  the  types  and  amounts  of  quality 
and  related  education  and  training  for  all  employees,  taking  into  account  their 
differing  needs.  Include:  (1)  linkage  to  short-  and  long-term  plans,  including 
company-wide  access  to  skills  in  problem  solving,  waste  reduction,  and 
process  simplification;  (2)  growth  and  career  opportunities  for  employees; 
and  (3)  how  employees’  input  is  sought  and  used  in  the  needs  determination 

-  how  quality  and  related  education  and  training  are  delivered  and  reinforced. 
Include:  (1)  description  of  education  and  training  delivery  for  all  categories  of 
employees;  (2)  on-the-job  application  of  knowledge  and  skills;  and  (3)  quality- 
related  orientation  for  new  employees 

-  how  the  company  evaluates  and  improves  its  quality  and  related  education 
and  training.  Include  how  the  evaluation  supports  improved  needs 
determination,  taking  into  account:  (1)  relating  on-the-job  performance 
improvement  to  key  quality  and  operational  performance  improvement 
targets  and  results;  and  (2)  growth  and  progression  of  all  categories  and 
types  of  employees 

-  trends  in  key  measures  and/or  indicators  of  the  effectiveness  and  extent  of 
quality  and  related  education  and  training.” 
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Notes: 


“Quality  and  related  education  and  training  address  the  knowledge  and  skills 
employees  need  to  meet  their  objectives  as  part  of  the  company’s  quality  and 
operational  performance  improvement.  This  might  include  quality  awareness, 
leadership,  project  management,  communications,  teamwork,  problem 
solving,  interpreting  and  using  data,  meeting  customer  requirements,  process 
analysis,  process  simplification,  waste  reduction,  cycle  time  reduction,  error¬ 
proofing,  and  other  training  that  affects  employee  effectiveness,  efficiency, 
and  safety.  In  many  cases,  this  might  include  job  enrichment  skills  and  job 
rotation  that  enhance  employees’  career  opportunities.  It  might  also  include 
basic  skills  such  as  reading,  writing,  language,  arithmetic,  and  basic 
mathematics  that  are  needed  for  quality  and  operational  performance 
improvement. 

Education  and  training  delivery  might  occur  inside  or  outside  the  company 
and  involve  on-the-job  or  classroom  delivery. 

The  overall  evaluation  might  compare  the  relative  effectiveness  of  structured 
on-the-job  training  with  classroom  methods.  It  might  also  address  how  to  best 
balance  on-the-job  training  and  classroom  methods. 

Trend  results  should  be  segmented  by  category  of  employee  (including  new 
employees),  as  appropriate.  Major  types  of  training  and  education  should  be 
noted.” 

Source:  Malcolm  Baldrige  National  Quality  Award  - 1994  Award  Criteria. 


C.4  People  Management  Capability  Maturity  Model 

Several  key  process  areas  of  this  model  are  concerned  with  education  and  training: 

Training  and  Career  Development:  Continuously  motivate  the  staff  to 
improve  existing  knowledge  and  skills  and  develop  new  capabilities  that 
enhance  their  contribution  to  the  organization. 

Knowledge  and  Skills  Analysis:  Develop  the  basic  data  about  tasks 
performed  within  the  organization’s  business  and  the  knowledge  and  skills 
they  require. 

Competency  Development:  Constantly  enhance  the  capability  of  the  staff  to 
perform  their  business  tasks  and  roles. 

Competency-based  Practices:  Ensure  that  all  people  management 
practices  are  based  in  part  on  the  knowledge  and  skills  of  staff  members. 

Source:  Curtis,  B.;  Hefley,  W.;  Miller,  S.;  Konrad,  M.  People  Management  Capability  Maturity 
Model,  Draft  Version  0.2.  Pittsburgh,  Pa.:  Software  Engineering  Institute,  Carnegie  Mellon 
University,  November  1 994. 
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C.5  Statistical  Control  and  Training 

Objective:  to  know  when  training  has  been  effective,  when  to  stop  training,  when  to  start  train¬ 
ing  in  a  different  area 

Use  of  control  charts  of  employee  performance  to  evaluate  training  effects  on 
performance 

Source:  Deming,  W.  Edwards.  Out  of  the  Crisis.  Cambridge,  Mass:  Massachusetts  Institute 
of  Technology,  Center  for  Advanced  Engineering  Study,  1982. 
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